Erlang vs. Java

[Richard A. O'Keefe]

Joel Reymont <joelr1@REDACTED> notified us about his
comparison of Erlang and Java at http://wagerlabs.com/ 
tech/2005/09/erlang-vs-java.html

I have two comments.

My first comment is that I found it very difficult to read.
In two senses.  I normally browse with an old Netscape, and
basically all I saw was a sea of black with a few dots of
colour here and there.  Once I switched to Mozilla, the
only trouble was that it was horribly ugly, the kind of stuff
which says more about the page designer than about the content.
Normally I would not bother to read anything which pays so
little attention to the needs of readers.  Please, PLEASE,
***PLEASE*** read Nielsen on web page design (http://useit.com).
The erlang-vs-java.html violates HTML readers' expectations in
so many pointless ways.

My second comment is that the comparison is grossly unfair to
Java in a rather interesting way.  Let's look at a typical
fragment of the code:

	private float callAmt;
	......
	public float getCallAmt() {
	    return callAmt;
	}
	......
plus a warning in the text that setters would add a lot more
code.  Well, if *I* were writing Java, I'd write

	private accessor<> float callAmt;

and the getCallAmt() function would be written automatically.
If I wanted a setter as well, I'd just change it to
	private accessor<> mutator<> float callAmt;

That's because I downloaded a copy of ELIDE.  The basic idea of ELIDE
is that when you notice a recurring pattern of code, you can define
a transformation (in a .elide file, which is Java extended with a
library for Java source code and something very like Lisp's backquote)
and then your user-defined annotation "transform<arguments>" triggers
the rewrite, which can add any number of methods.  ELIDE comes with
accessor<> and mutator<>, preconditions postconditions and invariants,
hooks into JUnit, the Visitor design pattern, and others.

Note that contrary to the comment in that web page, if you use ELIDE
to generate getters and setters (or anything else), the *generated*
code does *NOT* have to be maintained.  The Java+ELIDE programmer
need never as much as see it.  All that needs to be maintained is the
field declaration:
	private accessor<> mutator<> float callAmt;
It's not a matter of code being generated when you *edit* a program,
but when you *build* it, just like nobody maintains the C code that
the Yacc parser generates.

On the other hand, comparing Erlang binaries with explicit Java code
rather than Java serialisation *is* fair.  Erlang gets to inspect the
binary and decide whether to trust it, whereas Java serialisation means
letting the sender create an object in your address space (doing who
knows what in its constructor) *before* your program gets a chance to
look at it.

On the gripping hand, you could use ELIDE to define your own serialisation
protocol for your own classes (with, again, code generated at *build* time,
not *edit* time, so not being maintained by hand).


Of course you can do automatic generation in/for Erlang too.
In fact it's an area where Erlang shines, because the documented form
of parsed modules is so simple, and the whole language is so simple,
that it's a *lot* less work to build transformation tools for Erlang.
(If Java had been designed to make tools like ELIDE easier to build,
it would have been a *much* better language.)

And of course most Java programmers don't have ELIDE, but that's
their problem, not mine.  If I didn't have ELIDE, I'd do whatever had
to be done in M4, or build my own tools in Prolog or Erlang or Scheme.