23-Feb-2013 22:40, Russel Winder пишет:
On Sat, 2013-02-23 at 21:44 +0400, Dmitry Olshansky wrote:
[…]
I have to say that no amount of provided out of the box nice libraries
and top-notch GC help alleviate the dire need for plain value-types and
some kind of terseness (rows of static final int xyz = blah; to define a
bunch of constants). With Java version being 5 or 6 (as is usually the
case in production ATM) there is basically not a single construct to
avoid horrible duplication of information on each line.
Maybe in Java 1.4, 8 years ago a plethora of public static final int
constants, but these days seeing that implies a bad design, a complete
lack of updating/refactoring of the software to modern Java features, or
simple laziness. Java 5 introduced more than generics.
Admittedly I'm no expert on Java. Hence "have to work".
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)
};
There are lots of other cases, but this one is prime.
You might argue for using classes and inheritance + visitor pattern
instead of plain switch/state machines. The heaps of boilerplate to
write/generate all of "state"/visitor etc. classes argues the other way
around.
(and I suspect the execution speed too)
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.
Java supports value types, albeit as objects on the heap. Give me an
example of the problem so we can approach this with more than waffly
statements.
A trivial example is storage of pairs or tuples. That plus using Java's
containers makes memory footprint explode. At 100K+ hash-map I notice
quite high factor of waste. It's some double digits compared to plain C
arrays. I probably shouldn't care that much since servers are having
tons of RAM these days, and customers throw money on equipment without
second thought. Thus for the moment I just can't help but notice. Thank
god we are mostly I/O bound.
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.
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.
Sorry can't elaborate on exact details here, the work is not open-source
by any measure.
Far too few programmers use the final keyword properly/effectively.
In Java programs it can be used very often. I'd say too often since I
find it rare to have a need to e.g. rebind an object. As for "a few
programmers", well you have to type it everywhere, guess why it's not
popular?!
There are few shortcuts in Java 7, and even more stuff in Java 8 but all
of it is coming horribly too late and doesn't fix the "big picture".
Plus that has to propagate into the mainstream.
This is Java's serious problem. There are still people using Java 1.4.2
because they can't be bothered to update to Java 5 let alone 7.
And even if e.g. I for one would go for Java 7 it really doesn't depend
on my views at all.
[…]
I have many problems with Java, it is very verbose, but it needs to be
criticized in a fair manner not in a "slag off" way. Clearly everyone on
this list is going to prefer D over Java, but that is not permission to
use inappropriate argumentation.
Mmm. I report my experience not argument much of anything excpet that
it's far from pleasant.
If anything I might convince the team to switch off to Scala, someday.
If not the somewhat alien syntax it would be far easier.
--
Dmitry Olshansky
