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

[Dmitry Olshansky]

24-Feb-2013 14:34, Russel Winder пишет:
> On Sat, 2013-02-23 at 23:22 +0400, Dmitry Olshansky wrote:
> […]
>> Would be nice to know if there is something that can represent this C
>> snippet without the usual heaps of verbosity:
>> enum {
>> STATUS_OK = 0,
>> STATUS_FAIL_REASON_XYZ,
>> ... ad infinitum (but presently dozens)
>> };
>
>          enum StatusCodes {
>            STATUS_OK,
>            STATUS_FAIL_REASON_XYZ,
>          }
>
> Is perfectly valid Java.
>

You missed the point that these have to be the *real* integer constants
starting from 0. No frigging magic classes please.

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.

>> There are lots of other cases, but this one is prime.
>
> Job done then, Java is fine for your purposes!

Nice  irony but I've meant the cases for rows of "final static int blah" 
specifically.

If I had a power to fix a single thing in Java I'd say "remove redundancy".

> No point in philosophizing about performance, measurement is the only
> valid way of making any form of performance comparison.

Right.

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.

>>> The G1 GC is a significant improvements to Java.
>>
>> I guess this depends on the platform you (have to) use?
>> BTW I agree that Java's GC is nice, more so the automatic
>> de-heapification of modern VMs.
>
> No G1 is just nice.  I think it is standard in JavaSE and JavaEE from
> 7u6. Not sure about JavaSE Embedded.  Although JavaME is due a
> re-launch, I think it is dead in the water before being launched.

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

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.

>> Another example. I had to sort some objects by rating for a bit of
>> processing with ranking. Yet this rating is computed and really doesn't
>> belong with them at all (and needs locking beforehand) and I can't
>> reorder them in place. What I'd do is create an array of tuple
>> link-rating and sort these.
>>
>> In Java I have to create a full-blown object and allocate each array
>> slot separately, cool. Not to mention the complete lack of concise tuples.
>
> Without the code it is difficult to comment other than to say, are you
> using the right data structures for the job? Creating small short-lived
> objects is now highly efficient on the JVM, especially immutable ones.
> Support for tuples is interesting: Kotlin just removed them, Ceylon just
> added them. Java is nowhere!
>
>> Writing functors is a royal pain in the ass too. Anonymous classes
>> doesn't quite cut it on the scale of verbosity/benefit. If there any
>> library that doesn't use reflection like crazy to achieve simple,
>> concise functors, I'd be glad to use it but so far I found none.
>
> Java 8. You'll love it. Lambda expressions aplenty. Interestingly, no
> need for anonymous classes since it is possible to do call site type
> inferencing and use method handles and invokedynamic to get it all in
> place without an object in sight.

 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.

>> Sorry can't elaborate on exact details here, the work is not open-source
>> by any measure.
>
> In which case if you want help I'm available for consultancy!
>

Thanks, I'd gladly do.

>> Mmm. I report my experience not argument much of anything excpet that
>> it's far from pleasant.
>
> Different people like and hate different languages, this is only
> natural. I am surprised though how many people stay working in places
> using languages they do not and cannot begin to like.
>

Don't get me wrong here. Java as language is awfully verbose (above all) 
and lacking some simple features. Of these shortcut-like are the primes 
ones, I've mentioned functors, also e.g. unsigned data types are very 
useful sometimes.

Then as JVM platform it's perfectly fine for us at the moment due to it 
being:
a) mature and largely accepted (the key factor in favor of using it)
b) quite nice selection of tools in the standard library not to speak of 
reams of 3-rd party code
c) a VM. Like it or not but corps love VMs and safe isolated 
environments. For us the fact that it's cross-platform also removes 
quite a bit of pain, plus no memory corruption bugs etc.
d) friendly for plugins and dynamic (re)loading of these

Also given some constraints it turns out to be either code the whole 
stuff in plain C or split in Java/C parts. The C all the way down is 
definitely less pleasant.

D would probably fit perfectly were it not for:
a) Not widely recognized but sometimes we may cheat and tell it's C++
b) No support for loading shared libraries (bye-bye sane plugin 
architecture)
c) Lack of stable 3-rd party libs for pretty much everything
(this is getting better but is not there by miles)

>> If anything I might convince the team to switch off to Scala, someday.
>> If not the somewhat alien syntax it would be far easier.
>
> Scala has many pluses over Java, but also some minuses, as do the other
> languages such as Kotlin and Ceylon.

> There is also Groovy which can be
> both a dynamic and a static language these days and is closely tied to
> Java (but without all the verbosity), unlike Scala, Kotlin and Ceylon
> which have significant impedance mismatch in places.

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.

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)?

-- 
Dmitry Olshansky