Java > Scala

[Russel Winder]

On Wed, 2011-11-30 at 23:08 -0800, Walter Bright wrote:
[...]
> When you can implement a competitive malloc() using Java, I'll believe it has 
> reached parity. There's a reason why the JVM is itself implemented in C, not 
> Java. D's runtime is implemented in D.

This is like trying to compare apples and dog excrement.  Clearly malloc
will always be written in C.

I think this thread has shown that D folk need to accept that Java is a
critical platform out there and will be for many years to come.
Languages such as Groovy, JRuby and Closure -- the jury is still out on
Scala, and the Jury cannot yet even compare Ceylon and Kotlin -- have
evolved the milieu to be a active and efficacious one.  The point is
that the JVM arena, the CLR arena and the native arena are three
separate ones these days, with little or no crossover.

D's fight is with C, C++, Go, not with Java.  D needs to make inroads
into areas currently dominated by C and C++ and those being swept up in
the tide of Go.

If D is to be anything other than a interesting blip in the history of
programming languages it needs to gain traction from more than just the
core aficionados.

So which area can D compete well in, who are the people and
organizations who can show that D is better than C, C++, D, and Go in
these areas.  Why are they not out there doing guerilla marketing of D?

> Most Java benchmarks I've seen that showed Java being competitive were written 
> in Java (or at least Java style) and then ported to other languages. The reason 
> is because if you want to convert C, C++, or D code to Java, you have to 
> re-engineer it.

So people doing the benchmarks you have seen are substandard and don't
realize you are supposed to write the best idiomatic version of the
algorithm in each of the languages under test.  This is not a stick to
beat Java with.

> The reason escape analysis is used in the JVM is because the Java bytecode is 
> severely limited in what it can express. So, a language bytecode generator has 
> to bash its semantics somehow into that tiny vocabulary, and then the JVM has to 
> "reverse engineer" the intent back out of it. The effort poured into the JVM is 
> to recognize higher level Java constructs, not higher level Scala constructs, 
> hence the poor results from Scala mentioned in the article.

Fortran compiler writers have been doing this sort of thing very
successfully for years:  1960s Fortran 4 serial code gets converted into
parallel code by clever inferences and "reverse engineering.

It has always amazed me that owners of these old Fortran codes think it
is more important to expend resources on clever compiler trickery that
just to rewrite the codes in a modern language, like Fortran 2009.

Of course rewriting would give an opportunity to change language.  I bet
they would go to C++ not D.  Though staying with Fortran 2009 may be
even better.

So the real question here is to get some benchmarks together to show
that D outshines C, C++ and Fortran 2009 -- with of course the
benchmarks being written properly in idiomatic language for each
language not, as you noted earlier, transliterations from one language
to all the others.
  

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111201/b4102afe/attachment.pgp>