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

[Dmitry Olshansky]

26-Feb-2013 09:12, 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!


'cause they are read from network stream. Basically they are tags/IDs.
Then there is a read-dispatch loop based on combination of tags/IDs.

In a sense all of this execution state that is dispatched to can be 
encapsulated inside of a class. One class per ID that can be called 
Command or Packet. Then switch translates to visitor that visits packets 
as these are constructed from stream.

Then you can even chain visitors together etc. and it would be beautiful 
were it not for slowness and tons of boilerplate to create all of the 
classes. Again the above thing could be easily done with a table of 
functor once Java has lambdas.

Everything I need seems to require easy to use lambdas ... a disturbing 
thought.

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

M-hm. I'm not sure it would work when you actually store these as 
members of other instances like Command or Packet as above. But maybe 
JVM can cheat a bit even there I dunno.

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

Till then. But e.g. Scala claims to do just fine with this approach.

> […]
>>   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.
>
> […]

Mmm I wondering what does Go have to do with the topic at hand since it 
doesn't have direct C call mechanism and thus is worse then Java as I 
for one would call Go's GC quite pedestrian and  the ecosystem way to 
young. The other thing is that "it's from Google" won't sell it where I 
work at all (it will work against probably) since people are all 
technically skilled and have no respect for argumentum ad populum.

Again even Java was chosen given constraints and practical need. It 
wasn't my decision and I don't quite like it (I'm a newcomer there). 
Still I see the logic behind the choice and certain advantages it brings.

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

D is twice better then Go then: it calls C directly and has (will have) 
shared library support. For now it just calls into C's shared libs we 
need both ways and that's all. And Go is worse then Python still ;)

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

There are moments when I think that wasn't it for Google backing behind 
it (and the large cult of Google world-wide) that language would never 
get any kind of traction.

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

Okay thanks for the data point as I think I've seen some claims that 
Java can be compiled as Groovy (almost) as is... Well, back to the old 
painful way.

-- 
Dmitry Olshansky