TITLE: Less May Be More
AUTHOR: Eugene Wallingford
DATE: April 17, 2007  7:46 AM
DESC: 
-----
BODY:
Over at
<A HREF="http://lambda-the-ultimate.org/node/2124">
   Lambda the Ultimate</A>,
I ran into a minimal Lisp system named PicoLisp.  Actually,
I ran into a
<A HREF="http://software-lab.de/radical.pdf">
   paper</A>
that describes PicoLisp as a "radical approach to application
development", and from this paper I found my way to the
<A HREF="http://software-lab.de/down.html">
   software system</A>
itself.

PicoLisp is radical in eschewing conventional wisdom about
programming languages and application environments.  The
Common Lisp community has accepted much of this conventional
wisdom, it would seem, in reaction to criticism of some of
Lisp's original tenets: the need for a compiler to achieve
acceptable speed, static typing within an abundant set of
specific types, and the rejection of pervasive, shallow
dynamic binding.  PicoLisp rejects these ideas, and takes
Lisp's most hallowed feature, the program as s-expression,
to its extreme: a tree of executable nodes, each of which...

<BLOCKQUOTE><EM>
... is typically written in optimized C or assembly, so the
task of the interpreter is simply to pass control from one
node to the other.  Because many of those built-in Lisp functions
are very powerful and do a lot of processing, most of the time
is spent in the nodes.  The tree itself functions as a kind of
glue.
</EM></BLOCKQUOTE>

In this way an "interpreter" that walks the tree can produce
rather efficient behavior, at least relative to what many
people think an interpreter can do.

As a developer, the thing I notice most in writing PicoLisp
code is its paucity of built-in data types.  It supports but
three, numbers, symbols, and lists.  No floats; no strings or
vectors.  This simplifies the interpreter in several ways, as
it now need to make run-time checks on fewer different types.
The price is paid by the programmer in two ways.  First, at
programming time, the developer must create the higher-order
data types as ADTs -- but just once.  This is a price that any
user of a small language must pay and was one of the main
trade-offs that Guy Steele discussed in his well-known OOPSLA
talk
<A HREF="http://www.cs.uni.edu/~wallingf/blog-multimedia/steele-oopsla98.pdf">
   Growing a Language</A>.
Second, at run time, the program will use more space and time
than if the those types were primitive in the compiler.  But
space is nearly free these days, and the run-time disadvantage
turns out to be smaller than one might imagine.  The authors
of PicoLisp point out that the freedom their system gives them
saves them a much more expensive sort of time -- developer time
in an iterative process that they liken to XP.

Can this approach work at all in the modern world?  PicoLisp's
creators say yes.  They have implemented in PicoLisp a full
application development environment that provides a database
engine, a GUI, and the generation of Java applets.  Do they
have the sort of competitive advantage that Paul Graham's writes
about having had at the dawn of ViaWeb?  Maybe so.

As a fan of languages and language processors, I always enjoy
reading about how someone can be productive working in an
environment that stands against conventional wisdom.  Less may
be more, but not just because it is less (say, fewer types
and no compiler).  It is usually more because it is also
different (s-expressions as powerful nodes glued together with
simple control).
-----