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

[Scott McKay <address@hidden>]

At 06:17 PM 12/4/01, Dan Weinreb wrote:
>    Date: Tue, 4 Dec 2001 11:52:29 -0500 (EST)
>    From: Shriram Krishnamurthi <sk@cs.brown.edu>
>
>    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?
>
>The one thing that's clear is that lightweight languages are good and
>non-lightweight languages are bad.  Maybe that's the definition? :-)
>
>It's not clear to me that "having a read-eval-print loop" has
>something to do with the "weight" of a language.  Or that having
>lexical scoping is a "weight" thing.  I'm also not sure whether
>"weight" is more a property of the language definition in the abstract
>as opposed to a property of a particular implementation.

I've been wrestling with this question for a while, and here's what I've
come up with so far.  So far, I've just been "brainstorming" with myself,
and haven't introduced any rigor yet.
  (1) It should have a small, reasonably orthogonal core that has extensibility
       built in from the start.
  (2) Dynamically typed.
  (3) Highly layered approach to adding functionality.
  (4) It should be easy to provide interactive compilation.  This should not
      stand in the way of being able to compile reasonably efficiently.
  (5) Simple programs should require no extraneous boilerplate.

Here are some failures:
  - Java fails on 2 and 5.
  - Common Lisp fails on 3.
  - Dylan fails on 5, and arguably on 4.
  - Perl fails on 1 and 3.
  - ARC, I predict, will fail on 1.

I think the both the language definition and its *exposition* contribute
to its light-weight-ness.  Thus, Common Lisp could be described in a
fashion that makes it appear more light-weight.

I think that the following controversial things contribute to a language
having a lighter conceptual weight:
  - OO based on generic functions and multi-methods, because you then
    get to unify functions, method, over-loading, etc, into a single concept
    (and it's easier to meet criteria 1 and 5).
  - Lexical scoping.
  - First-class functions, because then things like generators, iterators,
    etc, fall out naturally.  Doing this really well depends on lexical
    scoping, although you can do an OK job without it.