Lambda the Ultimate

Jon Udell: Shipping the prototype
started 2/7/2003; 1:40:13 PM - last post 2/10/2003; 1:19:15 PM

Ehud Lamm - Jon Udell: Shipping the prototype

2/7/2003; 1:40:13 PM (reads: 1614, responses: 4)

Jon Udell: Shipping the prototype

Let's promote scripting languages to the status they deserve

Another take on the Should scripting languages be used for industrial strength projects question, inspired in part by the Guido van Rossum interview that was discussed here at length last week.

Things become more interesting when you try to enumerate programming language facilities that would help cope with a "world of distributed services in constant flux."

Perhaps the first thing that comes to mind is choosing interpreted over compiled languages. Naturally, this distinction is a bit naive, virtual machine bytecodes can enable mobile code just as well (if not better) than high level languages. But the classic model of compiling to platform specific object code is quite problematic, even if you take into account things like DLLs.

Next comes the issue of stand alone programs versus the language-as-runtime-environment approach exemplified by Smalltalk. The latter being a bit more natural for plug in components.

For foreign components to interact you will usually want some form of reflection or introspection capabilites in the language, and perhaps a way to access meta-data about components.

To manage the resulting menagerie of components, you would want the language to provide support for versioning, and hopefully some mechanism to ensure the integrity of the system, and that the components of the system are not inconsistent (think types).

Since failures are likely to happen from time to time, it is wise to require some contract support from the language, ideally support for sound behaviorial contracts and blame analysis.

Good language support for this sort of programming scenario will move the programming language into the land of languages-as-operating systems, since managing resources and cleanup for components is almost a must.

Smaller features can also come in handy. Things like automatic code updates from the internet, and possibly hot code replacement (think erlang).

All these issues were mentioned here in the past, with links to research papers exploring their implementation and interaction. I see no reason why many of these things can't be done manually, but programming language support would reduce programming effort and increase reliability.

Posted to Software-Eng by Ehud Lamm on 2/7/03; 1:55:04 PM

Michael Vanier - Re: Jon Udell: Shipping the prototype

2/7/2003; 2:58:39 PM (reads: 765, responses: 0)

If you want to get the benefits of scripting languages but also leave yourself the opportunity to "freeze" some of the code for (say) higher performance or greater safety (I'm thinking about adding static type information here) then it seems to me that soft typing is almost the only way to go. Currently, common lisp and dylan are almost the only languages in which this can be done, although PLT scheme should be there Real Soon Now. When you add macros (which can reduce code bloat even more) then the future starts to look pretty good for lisp-like languages.

Todd Coram - Re: Jon Udell: Shipping the prototype

2/8/2003; 6:04:33 AM (reads: 712, responses: 1)

It seems to me that people often say "scripting language" when they mean "high-level language" or "prototyping language" (when talking about higher productivity, rapid prototyping and fewer lines of code).

To quote Udell from the above mentioned article: "Languages that express programmers' intentions in fewer lines of code are a huge productivity win. The deliverable code is easier to understand and maintain -- and so, crucially, is the test infrastructure that supports it."

This does not mean "scripting language" by default. To the general programming public most high level languages tend to be scripting languages. But, then there are Lisps, Dylan, various FPs, Logo (yes, for simulation/education/games), Eiffel, Visual Basic, Smalltalk, etc.

For large projects, much of the productivity win of Python, Tcl, Ruby, etc are not the "scripting facilities" (although early on in development this is good), but the higher level language constructs at your disposal (closures -- or at least an approximation of closures, lists, list comprehension, dictionaries/associative-arrays, built-in iterators, string handling, and other facilities of expressiveness).

Ehud Lamm - Re: Jon Udell: Shipping the prototype

2/8/2003; 7:24:38 AM (reads: 748, responses: 0)

True enough.

Still, scripting languages, if such a language category really exists, tend to enforce abstraction boundaries rather weakly, thus making abstraction breaking easier. At times this can be A Good Thing.

Isaac Gouy - Re: Jon Udell: Shipping the prototype

2/10/2003; 1:19:15 PM (reads: 587, responses: 0)

scripting languages, if such a language category really exists

Perhaps that's not the problem.
Let's agree with John Ousterhout - "there are many interesting languages that can't be characterized cleanly as a system programming language or a scripting language."
And then take it further- we don't have good categories for those interesting languages, and many "traditional" scripting languages have changed so much that they are now among the uncategorized interesting languages.