[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lightweight languages



I like the phrase "lightweight languages," but I like it best when I
don't think too hard about what it means.  It may be helpful to use
lightweight to describing programs or programming tasks, and then
ask whether a particular language is good for lightweight programs.

I believe you and several others have observed that several common
sense of lightweight aren't a good fit:  If a language has a large and
useful library, how can it be lightweight?  How can a feature like
call/cc that is so difficult to learn be part of a lightweight
language?

On the other hand, I think there's a better fit for lightweight
programming tasks.  Programs that that will be run exactly once, where
you care most about getting the job done quickly and correctly.
Programs that explore a problem domain or possible solution; you're
planning to throw one away anyway.

Learning to program may fall into the category of lightweight tasks,
but I'm not sure the fit is as good.  Certainly the programs tend to
be lightweight, because you don't want to burden the student with
writing large or complicated programs that obscure the concepts.

If a programming language is good for lightweight tasks, it is a
"lightweight language."

In this case, having a few useful builtin/standard datatypes or
collections helps me write a small program quickly.

If a language is easy to learn, it allows a learner to focus on the
concepts of programming rather than the weird syntax or semantics of
the language.  The fact that the language also has call-cc is
irrelevant. 

Java and C aren't good for lightweight programs, regardless of whether
they have an interactive interpreter.

I suppose we could find lightweight languages, using this definition,
that are only good for lightweight tasks.  What's more interesting,
though, is lightweight languages that are also good for
programming-in-the-large. 

I think Ousterhout went wrong with his distinction between scripting
languages and systems languages [*] for the same reason.  The
distinction between scripting and systems programming seems fairly
clear.  The categorization of a language as a scripting or systems
language is unconvincing.  Lisp didn't fit at all, as he admitted,
because it's good for both tasks.

Jeremy


   [*] Scripting: Higher Level Programming for the 21st Century.  John
       K. Ousterhout.  IEEE Computer, March 1998. 
       http://home.pacbell.net/ouster/scripting.html