Bill Burke on Dynamic Languages: Rationalizations and Myths

"Am I just a Java fanboy?" - this is a good question.  And it is one that Bill Burke does answer in his blog post Dynamic Languages: Rationalizations and Myths.

Maybe, but I don’t think so. ... I also do not believe that Java is the end all, be all of existence. It still needs elegant, typesafe closures to complement annotations as a way to implement DSL. It needs a standard, non-code generating way of adding behavior to annotations. It needs a structural syntax to make initialization easier. AOP support might be nice too, or at least JVM support to make it easier to implement AOP-like features. Better zero-turnaround development features in both the JVM and APIs like Java EE, Seam, Hibernate, Spring, and JBoss AS would help out tremendously as well.

He continues on to say:

I’d be fine to dump Java for a language that supports all these things but the new language must:

• Be typesafe, statically typed
• Have an IDE that supports the same features as modern Java IDEs
• Have a rich set apis and libraries to build my applications from
• Have a viable commercial ecosystem
• Have a vibrant open source community

While current dynamic languages do have some of these attributes, none contain all, so until then Java is my choice and I will remain a boy who is a Java fan.

To get to this point, several rationalizations and myths are explored.  For rationalizations, there are:

• Dynamic Language XXXX didn’t do well against Java in XXXX benchmark
• Ruby VM cannot support kernel threads
• Dynamic languages like Ruby, Python, etc… are not typesafe/statically typed
• Lack of type safety doesn’t scale well to large teams
• Lack of static typing does not allow for reliable refactoring in modern IDEs

And the myths include:

• Software Engineers should use the best language for the job
• More lines of code means more bugs, thus dynamic languages are better.
• I am more productive in XXX dynamic language because the syntax is cleaner, more elegant, and more powerful.

More detail on each of these items can be found in the blog posting, but for the most part the arguments have been around for some time now.  Of more interest are the responses to the post.  John Wilson makes a good points for dynamic languages:

Dynamic languages are not a panacea but they are the preferred tool to address some problems.

Java is moving even further away from being easy to use by non professional programmers (yes, Generics, I’m talking to you). At this point adding stuff to Java is not going to make it easier to use. IDE help professionals but leaning enough about Idea, Eclipse or Netbeans to become dramatically more productive requires a large investment in time and effort.

We are erecting more and more barriers to entry to programming the JVM. If we continue to do this it will die. If the only way you can get code written for the JVM is to hire expensive superstar prima-donnas then the party’s over.

If somebody has a bright idea and can knock up an implementation in Jython, or JRuby or Groovy in a couple of days and it doesn’t work then they have lost very little. If it does take off then there may well be problems. It may be too slow it may not scale it may be hard to maintain (note there are only problems you hit if the app is successful). Then you can raise the resources to fix this problem (the Twitter guys don’t seem to have figured this out yet). However if the resource you need to get the initial implementation up and running then the number of ideas that make it from head to machine will reduce dramatically.

The problem is in how the Java community handles changes to the language. Everything has to be backwards compatible. No language feature can be changed for fear of breaking some application somewhere. In theory, I could take code I wrote in the 1990’s and run it on the latest JVM. This is madness. [No! This is Java! –Leonidas] The cruft forced on the language by this one decision accumulates and accumulates until features have to be hacked in by sheer force of will. Look at how generics turned out or the current dust up over the closure spec to see the real-world implications of this single design decision. ... The end result is a language and core community afraid of change.

Another response, from Enrique Utrilla, resonates the ideas of the polyglot programmer that Neal Ford has written about, as well as the language layer approach offer by Ola Bini and later by Stuart Halloway:

IMHO, it all boils down to the balance between three key concepts: productivity, ease of maintenance and runtime efficiency.

I might be wrong, but dynamic languages beat java in terms of productivity, much in the same way java beats c or c beats assembler. Yo can do things pretty fast, so they’re great, for instance, for prototypes and proofs of concept.

Ease of maintenance is were Java and the likes (and that includes .NET, Scala, and any other of your favorite non-dynamic high-level languages) beat dynamic ones. Refactoring is quite straightforward with modern IDEs, and loads of bugs are detected in compile time, while in dynamic languages they would be detected only in runtime, and worst of all, only sometimes.

My favourite solution would probably fall somewhere in between, provided there’s a good integration between languages. Code your critical algorithms in Java, the glue that joins them in whichever language suits you best. That should improve the performance of the application as a whole versus a pure dynamic implementation. This approach would be especially useful with Groovy given its similarities and flawless integration with Java (yes, I admit it, I haven’t work a lot with it, but it’s already my second favourite language). Again, it’s all a matter of balance.

The question I think we should be all be asking as developers is "where are we as a community?"  With developers moving between different languages and platforms, will there be a greater level of noob-ness or terse code from "superstar prima donnas" that needs to be re-written in order to be digested by those maintaining the software?  Should languages be easy enough to program in that we can avoid IDE's and allow non-professional programmers to start something, which we, as professionals, can take and extend with new features and non-functional attributes such as scalability? Will we progress past backward maintainability, or will the flexibility in dynamic languages allow us to add backward compatibility in where the language and library designers took it out?  And will Java's vibrant open-source community dwindle as those developers spread themselves across the many new dynamic and JVM platform language communities?

But back to Bill:

The real point of the blog was not to bash Ruby, et al, but to bash all the lame excuses

Hopefully from both sides of the fence.