On Programming Languages

I know Chris isn't implying dynamic languages are only for hobbyists, but any discussion of languages quickly starts to sort them for their attractiveness to developers on a scale from "hobbyist" to "professional developer".  Why?

This is a deep subject, fraught with ideology and emotion.  It is also an old subject.  To pick an arbitrary point in history, it goes back to LISP versus Fortran...with LISP offering a high level of abstraction and interactive development style, with obvious performance implications; and Fortran being very close to the underlying computer architecture, much more static in development style and promising (and often delivering) speed equal to hand-tuned machine code.  In fact, many of the ongoing debates over languages still revolve around basic design decisions found in LISP and Fortran:  compilation, static typing and garbage collection being obvious examples.

With all the intervening languages, development tools, and paradigm shifts, I think a lot of the debate still comes down to these two points:

Quickness of development versus Scale

Interactivity of development experience versus Performance of deployed code

To take two modern exemplars, consider C++ and JavaScript.  C++ requires the developer to carefully pre-declare all the resources he is going to use, how he is going to use them, and even where they are.  By this I mean mostly static typing, the requirement that everything be declared before use, and the header files that fall out as implication of the first two requirements.  In C++ the physical layout of your files is an important consideration, as it will dictate the architecture and the speed of your compilation (see the now somewhat dated but excellent "Large-Scale C++ Software Design" for the definitive treatment of these issues).  All this means there is considerable infrastructure and overhead to the development process, BUT properly done it scales well to huge projects with thousands of developers.  Without implying design-by-contract, C++ enforces contracts between different parts of the code, and between the developers that mean integration is more work, but more likely to succeed and with fewer bugs.  The explicit memory management architecture of C++ is another example.  You have to do a lot of work managing memory in C++...but done right it is very efficient and so explicit that bugs are readily apparent (well....errrr....except for all those nasty leaks).

However, having all this contract infrastructure in place makes C++ unsuitable for quick "playing around" coding, and in particular for interactive development.  You can't simply type a C++ class definition in to an interactive console and call methods on it while you're writing it.  Whereas in JavaScript you can.  In JavaScript you can add methods and properties to a "class" (differing definition of class from C++) at any time, and the code is almost always in a runnable state.  You don't have to pre-declare your variables, or type them statically.  You pay for this with performance, but arguably performance is less of a problem than it used to be.  With web apps, the cost of sending stuff across the line often swamps code execution time, and today's machines are much more tolerant of inefficient code (I remember the VAX at school being bogged to its knees whenever the LISP GC kicked in...and I mean it bogged all 100+ users on the system).   The real penalty of a language like JavaScript is the resulting spaghetti code, under-designed and buggy because issues that would be statically found by the C++ compiler only show up at runtime.

At this point, the two sides start to set up their camps and fortify them (on a similar topic, see Stephenson's essay "In the Beginning was the Command line" about the debate between the "professional-oriented" command line versus the GUI).  Which is unfortunate, because in the end I believe this will be a false dichotomy.  This is not about "Languages for Smart People" versus "Languages for the Masses" (which by the way, reverses the hobbyist stereotype, claiming C++ is for the masses, while LISP is the smart people language), and its not even about choosing the right tool for the right job.  It seems to me the proper solution is to keep advancing the art, and get the best of both worlds. 

Java, VB and C# are examples of this attempt.  All three now have static typing AND garbage collection (and runtime reflection, another classic property of LISP but not Fortran).  They don't require header files, but they do offer contracts (and even the promise of design-by-contract).  Pythalon is being developed as a mix of C# and Python code, and as I switch back and forth between the two I can't escape the feeling that these languages are converging.  The start up infrastructure of C# is certainly much closer to Python's than is C++, while Python has classes and strong (if dynamic) typing.  And the convergence is continuing:  ActionScript 2.0 and Boo respectively extend JavaScript and Python with optional static typing and stricter class semantics.  Meanwhile, Anders is adding more usability features to C#.

It almost makes me want to go work in the language business.