Erlang vs. Java

[Dustin Sallings]

On Sep 8, 2005, at 20:22 , Richard A. O'Keefe wrote:

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

     This isn't a valid complaint.  Although the page needs some  
minor changes to comply with the standard it's claiming, it's more or  
less what one would expect on any modern web site.  If your browser  
is ten years old (a really dark time for the web), you shouldn't  
expect things to work well.

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

     I think naming one or two of them would have been nice here.

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

     That is *not* java.  When you write this, you do not write  
java.  This is effectively saying you'd make a new language and  
transform it to java before compiling.  If I do that in vim, it  
points out my syntax error.  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.

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

     Right, but people will need to maintain this code at some  
point.  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.

     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.

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

     I don't quite understand what you're saying here.  Objects don't  
have constructors, classes do.  You can't deserialize a class the  
same way you deserialize an object.  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 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.

     I don't think it's fair to call something ``java'' that no java  
tools recognize.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@REDACTED>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20050908/673c4d9c/attachment.htm>