Complexity and Dynamically Typed Languages

Dietrich Kappe, Wednesday, November 1, 2006 @ 4:09 pm

idiomatic
-adjective

1. peculiar to or characteristic of a particular language or dialect.
2. containing or using many idioms.
3. having a distinct style or character, esp. in the arts: idiomatic writing; an idiomatic composer.

I finally listened to the Java Posse Podcast #088 last night. It's mostly Bruce Johnson doing the talking, which is fine. Robert and Ryan are smart guys with interesting things to say, but for the pure poop on GWT, Bruce is the man. Lots of interesting topics were discussed, including how GWT builds into a monolithic application that loads all at once. There's work underway in the developer community to support dynamic loading so that as applications get bigger, they can be dynamically loaded.

The most interesting aspect of the discussion, however, was the bit where Bruce Johnson explained why GWT came about. I had originally thought that Google just couldn't find enough qualified Javascript programmers and made lemonade out of lemons. Instead, Bruce said that the larger the Javascript/Ajax project in terms of code and especially programmers, the more complex and unwieldy the project became. I think he use term "idiomatic" to describe the problem with dynamically typed languages, and complained that good tools were hard to build because of the halting problem.

Now I understand what he means by invoking the halting problem. Unlike in statically typed languages, the creation of new types in a language like Javascript is part of the execution of a program. In a worst case scenario, you'd have to execute through the whole code in all of it's possibilities to get all of the possible type definitions. The program might in fact run forever, in which case your nice code completion logic will simply hang. And because of the halting problem (if you can determine whether a program halts, write a program that reads a program, and, if it halts, loops forever, but if it loops forever, halts. Then feed this program to itself.) you can't tell if a particular program actually runs forever or not, so there is no way to avoid the hang. All very tragic.

There are some ways around these issues. You can use heuristics, like the Aptana plugin for Eclipse, to take a stab at the types, or you can agree to write your type definitions in a particular way -- or idiom -- so they can be easily identified and parsed, but writing tools that rely on identifying types in your programs will always be a little harder to write for dynamically typed languages. And tools can be an important crutch, especially if the abilities of your developers are somewhat uneven. A good IDE can suggest or even enforce some rudimentary best practices.

But code completion and tools are a bit of a red herring here. I've always felt uncomfortable with programming languages that depend on good programmer behavior -- essentially obeying code level idioms -- to allow for the development of large, interdependent systems. Alex Russell, in my interview with him, argued that Javascript was a "more powerful" language than Java and cited this paper by Lutz Prechelt that claimed to show that scripting languages are moe powerful and productive than the statically typed, OO languages (in part -- it's a simplification of the thesis). I agree that I can do in 1 hour in Perl what it would take me 10 hours in Java. I might even hope, as a single developer writing my own well understood style of OO Perl, to write a large application more quickly in Perl than in Java. But add in multiple developers, and you start to enjoy the complexity problem that Bruce Johnson mentioned. The same, in spades, goes for Javascript.

In software engineering we implicitly assume there is a continuum of developer skill. The great developers are highly productive, the less skilled ones less so. I would argue that less skilled developers in a team environment are actually destructive -- i.e. they cause more work for other developers. I would further argue that the productivity curve for a language like Javascript is different than that for a statically typed language like Java. I have no data to back this up, but my impression is that the Java skill vs productivity plot is closer to linear, while the Javascript plot is more like a second order polynomial.

My experience with various dynamically typed languages, not the least of which was the horrible mess of OScript in Opentext Livelink -- a rogue dialect of Smalltalk and the Template method pattern gone horribly, horribly wrong, leads me to the conclusion that unless you have some really top flight Javascript developers on hand, you should try to keep your projects small and free of dependencies.

I'm sure this is not the last salvo in the battle between statically and dynamically typed languages, or OO vs Functional, but that's fine. My motto is "the right tool for the right job." And that tool may be Javascript, or Java or something else from time to time.

Technorati : ajax, gwt, podcast

agile ajax

Comments: 2 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   ”My motto is “the right tool for the right job.” And that tool may be Javascript, or Java or something else from time to time.”

   That’s a pretty narrow set of tools.

   Comment by Anonymous, Wednesday, November 1, 2006 @ 4:44 pm

2. 

   – My motto is “the right tool for the right job.” And that tool may be Javascript, or Java or something else from time to time. –

   That is also known as “The Plumber Rule.” If a plumber comes to fix your toilet and only has one wrench, fire him and call someone else. A good plumber will have a large array of tools and will use the right tool(s) for the task at hand, rather than trying to do everything with a “miracle wrench.”

   Comment by W^L+, Saturday, January 6, 2007 @ 11:51 pm

Leave a comment