RADlab, scripting and scale

I had a long and fascinating Wednesday with a couple of folks from Berkeley's new RAD Lab (press, home). While their public decoding of the acronym RAD is "Reliable Adaptive Distributed", they also care deeply about the more common decoding: "Rapid Application Development". The conversation was all over the map, but a major thread was about the design tension between scripting languages and strongly typed general purpose languages.

Over the years I've used and created a wide variety of scripting languages, and in general, I'm a big fan of them. When the project that Java came out of first started, I was originally planning to do a scripting language. But a number of forces pushed me away from that.

The biggest was concerns about performance and the inevitability of scale. I can't remember how often I've had experiences where someone has proudly shown me some system they've put together using the scripting-language-du-jour: things like an Adobe Illustrator clone written entirely in PostScript; a satellite groundstation diagnostic system written as TECO macros; a BASIC compiler written as Emacs macros; fourier transform algorithms in PostScript... This list is endless. They always ended with "this is so cool, but I'd like it to be as fast as {C,Assembler,whatever}". People get into scripting to quickly build small quick things, but they often grow far beyond where the initial concept started.

Another was about testing, reliability and maintainability. One of the common properties of scripting languages is brevity. This tends to lead to omitting declarations, weak typing and ignoring errors. Generally a great thing if you're quickly putting something together; not so great if you want checks and balances that crosscheck correctness.

Another is generality. Many scripting languages get a good part of their coolness from being specialized - by having key functionality wired into their hearts. A good example is perl, with it's great regular expressions and hash tables. But this drags in a number of issues, chief among them being: what if you want to do something outside the language's area of specialization? Many modern apps need to do exactly that, so one of two things happen: languages get used for wildly inappropriate things (fourier transforms in PostScript), or a collection of languages get used together (which can make it very hard for any one person to understand them, and interconnections can be a nightmare).

The list of interesting questions is really long, this blog entry could easily be a book (that I'll never have time to write). This hardly scratches the surface. The number of potential PhD thesis topics is huge.

December 15, 2005