Anxiety 2.0
Last weekend I attended the first annual WebDirections USA conference, in Atlanta, GA. My primary takeaway is that JavaScript on the server side will continue to make enormous gains comparable to those made by rails when it first appeared on the scene.
Yeah, that’s huge.
Of all the sessions, NodeJS and the expert panel resonated with me over the rest. The node session was a simple, thorough primer; nothing of any apparent philosophical value. However, the expert panel, and specifically a bold assertion made by Tantek Çelik, sent my head into overdrive. His thesis: in 5 years, every server side language will be dead or dying, being replaced by JavaScript. For a split second I merely giggled, and then I went somber; pensively spiraling into a future far different than the one I had imagined, and certainly different from the one I wanted to see.
This assertion did not sit well with me. The rails phenomenon shocked the web world, in many ways for the better, but it is a phenomenon I have never fully embraced.
On Friday night I engaged Tantek about this issue, hoping to gain a better understanding of his perspective, as well as my own, since he had dealt me a debasing blow. He clarified his prediction: in 5 years, all other language communities will have ceased to grow, and likely be in recession. Why? Ubiquity. JavaScript is the most widely deployed language on the planet, and huge numbers of people have at least some knowledge of it, as well as CSS and HTML. It is also a comparatively productive and relatively simple language, converging on what seems to be critical mass.
What do you get when you mix ubiquity, simplicity, and productivity? World takeover. Well, maybe.
I take issue with this idea. I have not yet fully formed my opinion, but the thought does cause me a bit of anxiety, and I shared this with Tantek.
What’s my deal? Am I sour that my preferred languages are not on the forefront of the next apparent revolution in web development? Maybe a little, but that’s hardly the crux of it.
Typing (integer.sayHello())
This is a battle that goes back decades. Dynamic interpreted languages are popular for at least two reasons: they are, or rather, they seem to be, simpler to learn and use, and they are more productive in the day-to-day development cycle. I am perhaps a minority among my fellow generation Yers in that I prefer static typing. No, I don’t like superfluous typing and no, I don’t merely want a static hint at what an argument is capable of (though you could make a fair argument for this). I prefer static typing because it is inherently more correct.
Static typing guarantees that, in terms of the expressed capabilities of a program’s abstractions, the calls made on these abstractions are logically sound. That is, during the compilation phase, if you call a method sayHello on an instance of Integer, the compilation will fail. It simply isn’t possible to make this mistake.
Further, many dynamic languages (PHP, ruby, python, javascript, …) allow arbitrary changes to arbitrary references throughout a program’s abstractions. That is, given an object Math which contains a reference PI, such that Math.PI equals 3.14159, it is possible for any piece of code to change that reference, such that Math.PI might then be 42, or 0, or “some arbitrary value of some arbitrary type.” In fact this practice, “monkey patching” as pythonistas call it, is embraced in many of these communities. You might call this flexibility, but on a good day I call this a poor facility for abstraction, and on other days insanity.
In a static language, this is simply not allowed. Some languages, specifically Scala (via implicit conversions), provide this same kind of structural flexibility without sacrificing static integrity. Static typing has a historical stigma of pain, but it is has improved in leaps and bounds. I only hope we haven’t lost the attention of developers.
Null (i = null; i.toString())
JavaScript, like most languages, supports the notion of a null pointer (or null reference). In most languages, including JavaScript, no tool will help you avoid this. Any object can be assigned this value, even in most static languages, in which it is viewed as a subtype of all types. In such an environment, a null pointer is a ticking time bomb. You get no help from tooling, so if you forget to check something (and we do this all the time), you get a runtime error. Seasoned developers struggle with this; it is a non-intuitive problem. On the other hand, many functional languages (like Scala and Haskell), employ monadic types to remove this problem.
The problem of null is neither new or superficial. The inventor of this concept, Sir Charles Antony Richard Hoare, spoke to an audience about the history of null, regarding it as a “billion dollar mistake.” Incidentally, he also says quite a lot about static typing in that talk, so I do suggest watching it.
Concluding
I think Tantek might be right, even if in a slightly lessened fashion. Further, while the future I want to see differs from the one I feel impending, I’m not in despair. Rather, I’m currently enjoying hacking on NodeJS, all the while seeking out what I see as the ideal future.
-
iamchrislewis posted this
