Meta-Erlang (was RE: Erlang vs Java revisited)

[Richard A. O'Keefe]

I wrote:
    > Programs are data.  My big complaint about older IDEs is that 
    > they encouraged people to think of programs as exclusively something 
    > human-written, when our best hope of reliable software is to write as little of 
    > it as possible.

"Vlad Dumitrescu XX (LN/EAB)" <vlad.xx.dumitrescu@REDACTED>
challenged:
	Is it the IDEs that did that? 
	 
I did not say that the IDEs *alone* encouraged that view,
but yes, they did encourage it.

I still remember someone from Xerox insisting fervently that
"A program is not a listing!"  The Smalltalk and Interlisp-D
environments were based on the idea that a program is a database
and that it is a database which programs may populate and
manipulate.

Smalltalk and Interlisp were not the kind of "older IDE" that I had
in mind, although I must say that they are older than the ones I did
have in mind.

Now some of the more modern IDEs have to some extent followed the
lead of Emacs and offer "plugin" features.  But the great thing about
Interlisp and Smalltalk is that you could write useful program-
manipulating code after reading a *small* amount of documentation.

The Java reflection API, including the new stuff that's needed to
do program transformation, is about as think as the local phone book.
I come to praise Erlang, not to bury Java, but the effect that the
syntactic complexity and irregularity of a language has on code that
manipulates that language is important.  Consider the whole
StringTemplate, er, scratches head for polite term, thingy.  To my
mind, it's a typically overcomplicated response to the fact that 
Java is pretty much hopeless at expressing data structures in source
code.  Working on the same kinds of things in Scheme, I never needed
more than backquote and maybe a few calls to a mapping function.

What has this got to do with Erlang?

Erlang *started* in a very promising way, as a language with just enough
syntax to do the job, very easy to parse and transform in Prolog, Lisp,
or Erlang itself.

But Erlang has never had the "a program is a database view", and there
seems to be constant pressure on it to adopt features that make it more
complex.  The preprocessor has to be the outstanding example.  Records
added a lot more syntax.  Anonymous functions added very little extra
syntax, and that of great value.  List comprehensions added more syntax,
although again it has a high payoff.  The whole Java-envy dotted module
name thing is an attempt to deal with a problem by working in terms of a
*listing* rather than a *database*.

What I am saying is that one way a language like Erlang can help us
produce reliable software is by making it *easy* to automate as much
of the code-construction process as makes sense.

Erlang makes it a lot easier than Java, but it's still not as easy as it
could be.  And the preprocessor is very definitely the wrong kind of way
to do it.