Erlang vs. Java

[Richard A. O'Keefe]

Dustin Sallings <dustin@REDACTED>
apparently believes that everyone should have the very latest of everything.
    > If your browser is ten years old (a really dark time for the web),
    > you shouldn't expect things to work well.

I didn't say that it's ten years old.  I don't know where he got that
figure.  It is four years old, and I like it because out of (recent Amaya,
Netscape, recent Mozilla, recent Opera) it is the only one which both
(a) by default displays readable characters on my 90 dot per inch screen
    (Amaya also does this)
(b) doesn't get confused all to heck by font sizes (when people much around
    with fonts Amaya tends to display them much TOO big).

I have better things to do than install new browsers every month.
(More accurately, I think our sysadmins have better things to do with
their time than install new browsers for me every month.)

He goes on:

    > That is *not* java.

It *isn't* Java, but it *uses* Java.

	This is effectively saying you'd make a new language and  
	transform it to java before compiling.

Wrong in an important way:  *AS AN AUTOMATIC PART OF COMPILING*.
It's no different from using Lex or Yacc or Yecc.

	If I do that in vim, it points out my syntax error.

So use a smarter editor.  I mean, generating Java is hardly new or
unusual.  What about JFlex (lexical analyser generator) or JavaCUP
or ANTLR or any of the other lex/yacc-style generators for Java?
There's a lot of stuff that people have been doing for a long time
*using* Java even though it "isn't" raw Java that they type.

	If I open that in eclipse, my project will just fail to work
	because it's not valid java and won't compile under a java compiler.

But it *does* compile using Ant.

The whole point that I am making is that you can *use* Java in a project
by writing in some more suitable notation which is automatically transformed
to java as part of the build process.  Things like JFlex, JavaCUP, and ELIDE
give you small steps up from Java.  What you write is Java *plus* a few
extra concepts.  It's definitely writing Java rather than, say, Fortran or
Smalltalk.

        Right, but people will need to maintain this code at some point.

Why?  This is the kind of stuff that gets "WARNING, AUTOMATICALLY GENERATED
CODE, DO NOT TOUCH THIS ON PAIN OF DEATH" plastered all over it.

	I've opened a lot of my projects in eclipse just for the sake  
	of having it detect certain errors (I've used several other analysis  
	tools as well...some work on source, some work on bytecode).  This  
	would not be an option here since you're really making a custom  
	language that's almost, but not quite java.
	
Of course it's an option.  The byte codes are standard Java byte codes,
the intermediate source code is standard Java.  Any tool that works on
byte codes should have no trouble.  Any tool that can work on standard
Java should have no trouble with the intermediate code produced by ELIDE.
But above all, one of the major reasons for using automatically generated
code is to get the benefits of code that doesn't *have* errors in the
first place.

By the way, I note that this idea of adding annotations is now an
official part of standard Java.  JSR 175 introduced annotations/metadata,
and they are part of Java 1.5.  See
    http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html
    http://java.sun.com/j2se/1.5.0/docs/guide/apy/GettingStarted.html
Quoting from the latter:

    Many of the intended use case for annotations involve having annotations
    in a base file hold information that is used to generate new derived
    files (source files, class files, deployment descriptors, etc.) that are
    logically consistent with the base file and its annotations.  In other
    words, instead of manually maintaining consistency among the entire set
    of files, only the base file would need to be maintained since the
    derived files are generated.  

ELIDE pre-dates this feature, but the two are extremely close.
So as of Java 1.5, this kind of thing *IS* standard Java, and any
"Java" tool which doesn't handle @<annotation> markup is out of date.

	     It's more like calling your yacc input ``C'' code to use your  
	example.  Sure, after running it through the special tool, it will  
	compile under a C compiler, but it's hardly C.
	
And my point is that *ignoring* this fact is like saying "C is useless for
writing parsers" without paying any attention to the fact that there are
tools that make it easy for people to mix parsing and C.

	     I don't quite understand what you're saying here.  Objects don't  
	have constructors, classes do.

Constructors do not run inside classes, they run inside objects.
An object's constructor is the constructor that is constructing it.

	You can't deserialize a class the same way you deserialize an
	object.

That may well be a deficiency in Java as it currently stands, but it
is not a necessary truth about OO programming languages.  In any
case, whoever talked about unpicking a class?  I certainly didn't.

	A deserialized object when being unmarshalled has to
	represent an instance of a class that is already available by
	name to the classloader that is deserializing it.

And your point is?  How does this in any way whatever contradict anyone
I wrote?  The classes that are available to the class loader by name form
a set that is determined AT RUN TIME.  This set need not be identical to
the set that was observable by the person who wrote the code that asked
for the object.  Indeed, it is most unlikely to be identical.  The point
is that "deserializing" an object *may* result in an instance of a class
that the programmer of the code that asked for it never heard of, so the
constructor may do things that the programmer of the starting class never
had a chance to consider.  (And yes, I am aware that "deserializing" can
run other things than constructors.)

	I don't think it's fair to call something ``java'' that no java  
	tools recognize.
	
Since ELIDE is a Java tool, it's fair.
We're not talking about a compiler that produces Java byte codes,
but a source-to-source transformer that produces standard Java which
"I only understand Java" tools *can* recognize, just like JFlex and JavaCUP.
Everything you have said against ELIDE seems to apply with equal force to
JavaCUP.  A grammar written in JavaCUP "isn't" Java, but it *uses* Java,
and a Java programmer could be excused for staring at you in astonishment
for suggesting that something which isn't strict Java syntax cannot fairly
be called Java.

Java is what you get when you try to sell Lisp in disguise to C++ programmers
and only belately realise you made too many concessions.  In effect,
annotation preprocessors are Lisp macros making a comeback.

I don't have Java 1.5 on my machines yet, but it _is_ a big step forward
compared with the old Java.

Erlang has had pluggable used-defined transformation for a long time.
I guess it just doesn't need it as much.