More on the dynamic language wave, but leave the poor vendors alone

The good folks over at Relevance have blogged again, offering something of a backhanded compliment to the new features of C# 3.0:

The argument that I infer from Ted’s piece is “Look! now we can have (some of) the expressiveness of dynamic languages with (most of) the safety of a statically typed language.” … But just because C# now looks a little more like some dynamic languages, don’t make the mistake of assuming that two worlds are converging. In the most important ways, they are as different as ever. Here’s why: Languages like C# “bake in” specific and detailed rules for inheritance, encapsulation, delegation, how symbols are interpreted, etc. In dynamic languages, similar rules exist, but they are not part of the language core. Instead, they are idiomatic extensions built within the language itself. Development teams can follow these idiomatic rules. Or, they can build (and enforce!) their own rules, specifically tailored to their needs. This has huge implications for productivity. In dynamic languages, you get to build the language up toward your domain, while you build the solution down.

Well, I’m going to take some umbrage at the inferred argument, in that I would phrase it as “Look! Now we can have some of the expressiveness and flexibility of dynamic languages without sacrificing the safety of a statically-typed language”, so I’d say they got it half right. But the idea that a dynamic language doesn’t have specific and detailed rules regarding inheritance, encapsulation, delegation, and so forth, is a fallacy: they have them, they’re just not the same rules as those for a statically-typed language. Make no mistake about it: if C# or Java wanted to have the ability to support type reification like that supported by languages like Self, it could do so without too much difficulty–code could modify the core type tables in memory, adding methods, removing methods, even hooking in to the basic method execution processing code that the JIT compiler creates on the fly for both environments. The basic truth here is that the creators of the JVM and the CLR didn’t believe in such things, and more importantly, didn’t believe such things justified their costs in general-purpose programming langauges.

Folks, we need to realize something: all this “expressiveness” is like putting craftsman’s tools in your hands; in the hands of a master craftsman, amazing things can result, but in anybody else’s hands, it’s putting a loaded gun into the hands of a child. YOU may be good enough to be disciplined enough to keep the rules of your types in your head when programming with Ruby, but are all of the programmers on your team equally gifted? Are all of the programmers that will follow you so gifted?

There’s something else that they call out here, though, and that’s the part that irks me:

So why has the static/dynamic debate staggered on for so long? I think we could get closer to some answers with better choice of terms. “Static” vs. “dynamic” is highly misleading. I propose we use a new set of names: vendor-oriented vs. developer-oriented programming, or VOP vs. DOP. So who do you trust most: vendors or developers?
I find this argument highly unfair and totally bigoted. It essentially suggests that vendors can’t do anything right, and portrays them in the traditional “corporations are the root of all evil” that right now so deeply permeates the American social landscape. It also portrays everything done by “non-vendors” (whomever they are) as pure and white and good; never mind the ten thousand open-source Web framework projects on Sourceforge that all do mostly the same thing, just with a slighly different vision or API layout. (Quick, somebody tell me something that Ruby can do that ECMAScript can’t. Or Cincomm Smalltalk, for that matter.) For crying out loud, guys, get off the Libertarian rally train for a moment and at least cough up some kind of concrete criticism–after all, after all, HTML was defined by evil vendors, too (in the none-too-subtle guise of a “standards committee”), and I don’t see us rushing to abandon that any time soon. Nor do I want us to. If you choose to distrust all vendors, then feel free to do so, but riddle me this: if you sell code for a living, aren’t YOU a vendor too?