Tuesday, October 18, 2011

Built-In Obsolesce

Here’s another of those thoughts that has nothing to do with software but that I think is interesting enough that I want to post it.

I am a huge fan of science fiction, and I just got done reading a brilliant book by one of my favourite authors, China MiĆ©ville, called “Embassytown”. MiĆ©ville does not disappoint with his latest work; mashing up New Weird and Space Opera to create a most thoroughly enjoyable yarn. I highly recommend it!

This story got me thinking about the cultural evolution of sentient species. The one concrete example I have leads me to believe that the same sentiency that allows these species to dominate their worlds, also all but guarantees that they will all eventually self-destruct in the rare case that they are not made extinct by some environmental catastrophe. Though their demise will probably be brought about by technology-accelerated runaway consumption (as my subject species is demonstrating), I suspect that there is a more subtle reason why their demise is inevitable: the species-wide nihilism that I assert is inevitable as the species unravels the mysteries of its own existence and the Universe.

As the human species begins (and I do assert that we are only in the paddling pool of self-discovery) to unravel the nature of their own existence and the Universe of which they are a infinitesimal part, one by one the things that they imagine are vitally important will become meaningless. For example, how can the significance of any individual’s hopes, dreams, aspirations, desires and beliefs, stand firm in the face of an understanding of the biological evolutionary process. I would assert that they cannot.

George Bernard Shaw wrote the following about Darwinism in the preface to Back to Methuselah:

“But when its whole significance dawns on you, your heart sinks into a heap of sand within you. There is a hideous fatalism about it, a ghastly and damnable reduction of beauty and intelligence, of strength and purpose, of honor and aspiration, to such casually picturesque changes as an avalanche may make in a mountain landscape, or a railway accident in a human figure.”

Note: Shaw wrote this as a criticism of Natural Selection; he was a Lamarckist.

Though there are still many who do not even believe in Evolution, let alone understand it well enough to come to this miserable and inevitable conclusion, it is an unstoppable meme; inevitably all of humanity will come to understand it, assuming we don’t self-immolate first of course. And when the entire species succumbs to this meme it will simply expire from collective nihilism. Perhaps this is why there has been, and continues to be such resistance to this so-obviously correct idea; on some level our genes “know” that this level of species-wide self-awareness is fatally dangerous. And Evolution is not the only dangerous idea that undermines the human condition.

I am a self-confessed Nihilist and Atheist so maybe I am just projecting, or this might just be my attempt to understand the Conservative and “Anti-science” worldview.

It should be kept in mind that I had a smile on my face the entire time I was writing this. I don’t take myself too seriously and neither should you.

Wednesday, October 12, 2011

The Argument from Vitriolic Invective

I was sent the following link after posting yesterday about node.js:


I think it is safe to say that Ted Dziuba thinks that event-driven systems in general, and node.js specifically, are bad tech. And he is particularly insistent that JavaScript has no place running on “The Server”. I am all too familiar with this particular song. While working as a Technical Evangelist for the .NET Framework, and then working as the Performance Program Manager for the CLR, I heard it played more times than I have heard “Elmo’s Song” played, and my kids are one and three, so you get the point.

When .NET came on the scene at the turn of the century I heard a cacophony of grumblings from the Java community about how it would never rival the performance of the [whichever] JVM or the breadth of the JDK and 3rd-party Java libraries, from the C/C++ community that its performance would suck so badly that it would be unusable for high-performance workloads, from the Visual Basic community that it would never replace good-old VB, and from the academic community that it would never be suitable for teaching or research. They all turned out to be mostly wrong. Yes, there are some workloads that still need C/C++ because of their extreme performance requirements, but for the vast majority of workloads well-written .NET Framework code holds its own (and not to mention the developer productivity gains!). And obviously the .NET Framework’s performance has improved over the decade so there remain few workloads which are beyond its capabilities. Of course anyone can write poorly performing code, but that is equally true for C++ as it is for Erlang, Scala, Java, C#, F# or TSQL.

So what’s my beef with Mr. Dziuba’s post?

Obviously he knows his proverbial stuff, but this post comes across as nothing more than a bitter rant, despite the fact that it has “math” in it. And his assertion that “threaded programming, … is easier to understand than callback driven programming” made me literally laugh out loud. Perhaps it is true for him, but for the vast majority of developers out there multi-threaded programming is a source of wide-eyed terror; the appropriately ominous words “deadlock”, “race condition”, “convoy”, “starvation” and “Heisenbug” come to mind. Perhaps he is correct about the performance characteristics of multi-threaded versus event-based systems, but in the end if node.js is good enough for most workloads, and is easier for developers to work with, then who gives a rat’s arse.

His final assertion that JavaScript in not appropriate on “The Server”, also made me laugh; as if the server is some sort of sacred ground not to be touched by the unwashed feet of a lowly scripting language. Node.js is based on the V8 JavaScript engine from Google, which compiles the JavaScript down to native code on first execution and has a few tricks up its sleeve to avoid the performance penalties associated with dynamic or “duck” typing. No, it’s not as fast as an equivalent C, C++ or x86 assembly program, but I don’t doubt that it will perform adequately for the majority of use cases. And JavaScript is not standing still either. Not satisfied with having the fastest JavaScript runtime, Google today announced an early preview of Dart; a new language that is based on JavaScript that, among many other language enhancements, addresses the performance limitations of the current incarnation of JavaScript. It will run as native code on the server or as compiled JavaScript in browsers that don’t support it natively, which is currently all of them including Chrome. Unfortunately V8 does not yet natively support Dart either (though I don’t doubt it soon will), and there are no binaries available, so if you want to play with it you are going to have to download the source and build it yourself.

Companies like Intel are also working on providing technology that addresses the performance issues with JavaScript. JavaScript is already the dominant client-side development language, and it looks like it may soon have a significant footprint on “The Server” too, despite Ted Dziuba’s strong objections.  

Tuesday, October 11, 2011

Architecting Simplicity

I am amazed at the plethora of products and technologies that are required to deliver a best-of-breed, leading-edge, enterprise-scale, line-of-business software system.

As an example, a system that I am currently working on has an architecture that uses the following products and technologies:

None of the aforementioned technologies are being used gratuitously; the architecture that aggregates all of the above is necessarily complex, given the requirements. A senior developer working on this project needs to understand all of these technologies and will be writing “code” in HTML, CSS, JavaScript, XML, C# and TSQL on a daily basis. That’s a lot of tech to wrap one’s head around. And that does not include understanding the domain “problems” that the system needs to solve, which are typically complex in their own right. And this amount of technology is not atypical for enterprise line-of-business application development.

Does software that solves complex problems really need to have so many moving parts? Isn’t Simplicity one of the core tenets of great software design? 

I recently had the opportunity to chat with Rob Boyes, a Technical Director at airG, about the technologies that they are using for their latest product and service offerings. airG is a leading mobile social entertainment provider based in Vancouver, and they have millions of users from across the planet using their software. Rob told me that, though in the past they have used the LAMP stack for their backend platform, they are now using node.js and mongoDB. Though I knew of the existence of mongoDB, I had to admit to Rob that I had not heard of node.js. Since I love nothing more than tinkering with new software technology, this conversation motivated me to do a little hands-on research into these technologies, and I have to say that I have been super-impressed; these two technologies are, in a word, “awesome”! And much of that awesomeness derives from their elegant simplicity.   

node.js, or just “node”, is a server-side JavaScript runtime based on Google’s V8 JavaScript Engine; the same JavaScript engine that is in Google Chrome. It includes built-in HTTP support (though it is not limited to the HTTP protocol for network IO).

Here is a very simple example of node JavaScript code:

var http = require('http');
http.createServer(function (request, response) {
   response.writeHead("Content-Type", "text/html");
   response.end('<html><body><h1>The Barbarian Programmer</h1></body></html>');
}).listen(8000, "");

Obviously being able to write JavaScript on the server gives web applications elegant symmetry, but node’s execution model is also very simple; the runtime, which will run on just about any modern operating system, runs user code on a single thread (though the runtime itself is multi-threaded). Request processing is non-blocking and is based on an asynchronous event/call-back model, so the entire server is super-scalable, and developers do not need to concern themselves with pernicious thread synchronization issues. There is also nothing to stop you from running multiple hardware-thread-affined instances of the node runtime on a single box  and using a load-balancer, probably also running on node, if you want to take advantage of multiple cores or CPUs for additional scalability and/or throughput. How to Node is a good place to learn about all things node.  

There are also a lot of additional JavaScript libraries for node, including Connect and express, which further simplify the development of web applications. There is also a great package manager available for node called npm, which makes installing these libraries dead easy. It is currently “experimental” on Windows.

mongoDB is a super-scalable “document-oriented” database, which natively supports the storage and retrieval of JSON(ish) documents. This makes it the perfect choice for use with node.js. A node.js driver is available for mongoDB, and drivers are also available for just about every platform under the sun, including the .NET Framework. mongoDB binaries are available for Windows, Linux, OS X and Solaris, and since it is open source, so is the source code. You can install the node.js drivers using npm.

When node.js and mongoDB are combined with HTML50, CSS3.0, JQuery and client-side JavaScript they represent a super-scalable, simple, consistent, and powerful web application platform. And it’s JavaScript (and JSON) all the way down! Obviously these technologies are not going to be suitable for every type of application, but I will most definitely be looking for opportunities to use them in upcoming systems that I design. Perhaps you should too.

Mad props to Rob, for reminding me that there are indeed new things under the sun.