D and Java [was Re: The DUB package manager]

[Russel Winder]

On Sun, 2013-02-24 at 15:49 +0400, Dmitry Olshansky wrote:
[…]
> You missed the point that these have to be the *real* integer constants
> starting from 0. No frigging magic classes please.

I am not sure why they have to be hardware integers, this is a JVM-based
system and hardware integers do not exist. I feel a contradiction
between requirements and technology here!

> Citing Oracle:
>   All enums implicitly extend java.lang.Enum. Since Java does not 
> support multiple inheritance, an enum cannot extend anything else.
> 
> My thoughts after reading this: "holy crap, they are class instances". 
> Even then we seem to use enums where there is no need for integer 
> constants specifically.

Safe Enum pattern/idiom is indeed all about the representation of the
symbols being instances of a class. But small immutable objects are very
cheap these days on the JVM.

It is possible Java 9 or Java 10 will remove the primitive types
completely so that all variables are reference types leaving it to the
JVM to handle all boxing and unboxing internally thus making things a
lot more efficient and faster.  Experiments are scheduled and underway,
decisions made only once the results are in.

[…]
> It however doesn't prevent one from observing the potential bottlenecks
> in e.g. parsing binary packets. Measuring is good but in server/distrubuted
> context is highly non-trivial to do correctly.
> 
> Like I said earlier the current project (the one I go by) is largely I/O 
> bound (and that's not network but rather the "device" I/O). I did 
> synthetic benchmarks back then and in short visitor sucked.

I'm not sure where "visitor" fits into this, I may have missed
something…

[…]
> Then it's in Java 7? Okay, now I have a solid argument to bring about 
> the switch to Java 7 :)

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html

G1 is the default in Java 8, but you have to switch to it in Java 7 if I
remember correctly.

> Seriously, of course, we tend to switch to whatever is perceived as 
> stable in the "local market". Currently it was Java 6. Newer projects 
> would be 7 I guess.

Any Java user still planning to stay with Java 6 or earlier and not
planning to switch asap to Java 7 will be on their own very quickly and
seen and just another legacy problem.

[…]
>  From what I read about Java 8 it is tolerable (as the language). Still 
> a far cry from D but largely more usable then now.

Java 8 and Groovy (also Scala, possibly Clojure, Kotlin and Ceylon) will
make it hard for any organization with a JVM heritage to even
contemplate switching to native.

No matter how good D is compared to C++ or Java, if there is no easy
route for take up, D will remain is the traction position it currently
is.

[…]
> D would probably fit perfectly were it not for:
> a) Not widely recognized but sometimes we may cheat and tell it's C++

With the current marketing strategy, this is how D is going to remain. D
does not have an organization such as Google pushing it as Go has had.
Yet there is a strong analogy: Go is C with warts removed and modern
stuff added. D is C++ with warts removed and modern stuff added. Go has
a small hardcore that is active and outward looking trying to create
replacements for all the C and Python codes that people actually use. Go
sells itself on the purity of the concurrency model and it object model,
not mention GC. D on the other hand has a small hardcore. 

> b) No support for loading shared libraries (bye-bye sane plugin 
> architecture)

Go has eschewed all dynamic linking and is making this a feature. But it
has a mechanism for being able to call C from libraries. Python has a
mechanism for calling C from shared libraries. D is at a disadvantage.

> c) Lack of stable 3-rd party libs for pretty much everything
> (this is getting better but is not there by miles)

Go has managed to attract volunteer labour to write in Go new versions
of everything previously written in C other than actual OSs. But even
there people are beginning to write OSs in Go.

[…]
> Yay, Groovy! I've pushed for using it recently for web application in 
> favor of "evolving" some legacy JSP-based hell. BTW you are solely 
> responsible for me ever knowing about it in the first place.

Sponditious :-)

> Hmm. An OT question - how hard it is to convert some moderately sized 
> app to Grovvy from Java (just to see if it looses anything in terms of 
> performance, in static mode obviously)?

No tools for this as yet, so down to manual transform. First step though
is to run the Java through the Groovy compiler and see what happens.
Once you have something compiling you refactor the code replacing Java
verbosity with Groovy terseness until there is nothing left to refactor,
you have a "pure Groovy" codebase.


-- 
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 winder.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/20130226/813a29f8/attachment.pgp>