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
