Re: Var-free programming (slightly off-topic)

[address@hidden]

      Lightweight languages rule.

   So, the big question that didn't actually get addressed at the LL
   conference: what is the criterion (or what are the criteria) for
   distinguishing between a "lightweight" language and other kinds of
   languages?

I have one definition. A LL is one that you can design & implement with not
too much work -- two, three days to get a really good implementation. That
means you can afford to build a purpose-directed language for a single task
or a small set of tasks. Got a problem? Build a language... then solve your
problem.

Scheme & Lisp macros are the only existing technology that provides this.
Thus the talks that Shriram & I gave.

Another definition might be "languages that have a small footprint," for
some definition of footprint -- cognitive, RAM, interface complexity. So
TCL, being designed to be implemented as a little bitty interpreter you
can link in to any set of core-functionality C code, would be a lightweight
(albeit horrible) language. Perl is not lightweight. Common Lisp is not
lightweight. They are both large, complex things.

   The one thing that's clear is that lightweight languages are good and
   non-lightweight languages are bad.  Maybe that's the definition? :-)

No, I think of C and Java and ML as being heavyweight languages, and I like
them all, and think they are important. I don't like perl, but it is certainly
important. TCL is lightweight, and it is truely awful. So lightweight doesn't
imply good, and heavyweight doesn't imply bad. Sometimes you need a
heavyweight language to do some heavyweight work.
    -Olin