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
