Jon Udell on DSLs. I think he has it right. DSLs are the way of the future. You only need to look that the proliferation of XML flavors used in the Java world to see that basically everyone has decided that using a DSL is better that writing Java code. I think this is especially telling in that XML is a horrible programming language and still using XML is easier/better than hand coding it in the generic language. Just imagine what could happen if these languages were designed to be easy to understand.
One of the reasons I really like Ruby is that it is easy implement stuff that looks and feels like syntax but is really just normal code. This allows you to extend the languages in ways that make your code more obvious. Just take the member access decorators as an example. If you want to make a method private you do the following:
private def my_method #do something end
In most languages the “private” is a keyword that the compiler understands but in ruby it is just a class method that says “future methods defined on this class are private until otherwise specified”. The power of this is pretty amazing when it is used correctly.
Another example is Rake (I stole these examples from Jim Weirich’s Rake tutorial). Rake is yet another build system like Make and Ant but it implemented as a set of extensions to Ruby so that your build script is straight Ruby but the common operations, like task dependencies, are expressed succinctly and in a way that is easy to understand. For example
file 'main.o' => ["main.c", "greet.h"] do sh "cc -c -o main.o main.c" end
‘file’ defines a task that creates a file. File tasks know things like: if my file does not exist or any of the files on which I am dependent are newer by my file I need to execute, otherwise I am a no-op. Just think how much less obvious it would be if you were to write that out in general purpose language — or in an XML dialect. And even better you have a full strength language at your disposal if you need to do something that the build systems developers didn’t anticipate, which you will.
Back to Jon’s article. I am not sure if there will be a consolidation of environments, in the near future at least. It would be really nice if this were true but there are problems with all the obvious contenders. Most of the open source community will not accept a VM that is not fork-able (by which I mean that they cannot fork the code base if they do not like the direction it is moving). The Sun JVM is proprietary and the only open source JVMs are incomplete. The .NET CLR is an option but everyone is afraid of MS. The CLR is probably safe because of it’s status as an ECMA standard but there does not seem to be much movement to port existing languages to the CLR even though Mono claims to be in pretty good shape these days. Then there is Parrot — the Perl 6 VM — but it is not complete yet and it is not clear when it will be ready or how well it will support non-Perl languages.
You may have noticed the above is mostly about what the open source community will accept. I think most of the innovation in programming languages and DSLs is coming out of the open source community right now. There has some movement toward more inclusion in the commercial offerings. Sun has been adding support for dynamic languages with BSF and Coyote and the .NET CLR has always supported multiple languages. However, I think that if there is an environment consolidation it will be because the open source community comes to a consensus that there is one or two platforms that are good enough for all their needs. I know both Parrot and Mono want to be this platform but neither of them are there yet nor are any of the commercial VMs. It will be interesting to see what happens.
{Update: Fixed the description of the private access modifier in in Ruby. Thanks to obsolete rubyist pointing out that I had gotten it wrong.}