Re: lightweight languages

["David McClain" <address@hidden>]

Jeremy Hylton writes:
------------------------------
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.

....
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.

--------------------------

I have an experimental language that I have been using almost daily now for
about the past two years.. It pretty well fits this description. It is a
language for performing ad-hoc calculations and numerical modeling for
scientific data analysis, primarily aimed at image processing -- but it has
many other uses as well.

It was patterned intentionally after the OCaml syntax and semantics, but it
is dynamically typed, instead of statically typechecked. Hence it allows the
creation of unsafe programs. But more importantly to support this kind of
lightweight investigative programming, all the math is vectorized -- meaning
that math operations apply equally well to scalar values and entire
multidimensional arrays of values. Vectors and matrices can be easily sliced
and diced with terse syntax.

Being patterned after OCaml allows very expressive programming with
recursion, tail optimization, record structures, tuples, lists, etc. Lists
do not need to be homogeneous as they must be in SML and OCaml. But
furthermore, this kind of powerful syntax and semantics means that the
non-numerical programming is just about as lightweight as the numerical
stuff. Things like interacting with the user, managing file I/O, etc. Up to
now numerically oriented modeling languages have tended to make the numerics
very easy, and totally ignore the issue of the non-numeric stuff. As a
result, in those languages one gets bogged down by the inevitable
non-numeric portions of the programming task. My NML sought to equalize the
burden for non-numeric as well as numeric tasks.

Compilation proceeds directly to compiled OCaml closures -- i.e., pretty
fast stuff -- not just bytecodes. These are directly executable and provide
a 2x speed up over the likes of Matlab or RSI/IDL and PVWave.

All in all I have to declare this language a definite success, even if it is
my baby. But I would not imagine using it for such things as writing
compilers, building network servers, and such. It is aimed at a narrow
problem area and it performs with lightweight characteristics in those
areas.

For those interested, you can find out about this language at
http://home.mindspring.com/~dmcclain1/nmlpromo.htm

Cheers,

- David McClain, Sr. Scientist, Raytheon Systems Co., Tucson, AZ