BT

Bill Burke on Dynamic Languages: Rationalizations and Myths

by Ian Roughley on Feb 13, 2008 |

"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.

Hypothetical Labs, in a response posting sees Java's legacy as a problem to the features that Bill proposes:
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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

open source by Matt Giacomini

One of the things I'm interested in seeing is weather we start seeing off shoots to Java down the road, now that it is open sourced. Seems that it would be reasonable for a group/company with a new vision for a type of Java could leverage the existing java source code as a base to strip down and/or build in features. I know that a product along these lines would no longer be "Java", but I can imagine that there would be a lot of interesting possibilities.

or maybe I'm wrong and the creative and crazy winds that used to blow through Java sails are now blowing elsewhere.

Re: open source by Jean-Jacques Dubray

Why choose when SCA can give you the best of all worlds as long as you can define clean inter-actions between your components?

For instance, orchestration languages are used increasing because they solved some real-world problems more easily than traditional programming languages. Should we wait until Java implements orchestration concepts? should we migrate everything from Java to BPEL. None of these alternatives sound right. SCA brings orchestration to any traditional language. Now, you could replace BPEL by XXX dynamic language and I would think the paragraph would read just as well.

JJ-

Isn't every unit test based on a certain scope/domain by Arjen van Schie

If I understand it correct, your vision can be summed up to this: BDD & TDD are bad for unit testing, because the tests are aimed at testing only the known required behavior and neglect to test the whole unit.
If so, I wonder how you write unit-tests to fully test an unit; the whole scope. For instance, I can't remember to see an unit-test that really tested an unit with all possible values for all parameters for all methods , and in all combinations. This would lead, even for the most trivial cases, to an unlimited amount of test cases.
An example: a class with one method "int add(int number, int number2){return number1+number2;}". To fully test this method I would have to call this method with all possible values of int for both parameters. Which results in more than a million testcases. And even in this case I neglected the role of class-state created by method calls.
Off course I can assume that if the method works for add(1,1) I can be pretty sure it works for add(1,2) but you never know for sure until you verified it. (it could very well result in bugs: if there are bugs in the compiler or hardware or ...). You can only ‘assume’.
Now for most software the number of test cases can be narrowed down a lot based on this kind of assumptions. But are these kind of assumptions not a derived variant of the assumptions you make with BDD and TDD ? And if so, why not make these assumptions a little broader, as is the case with BDD, so you just check the expected usage (in the agile state of mind only do what is essential / necessary ), what’s so bad about that ?

ActionScript 3 by serge ----

Bill,

Isn't ActionScript 3 optional static typing? Wouldn't this fit your ideal scripting language?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT