|
Re: The Positive Legacy of C++ and Java
|
Posted: Apr 1, 2009 4:00 PM
|
|
> > I know there is a learning curve, and that once you get > > used to doing something, it becomes easier. But one > good > > thing about Java is that the curve was always short, as > > was the "getting used to it" time. > > It's funny that you use 'was always short' instead of 'is > always short'. I say that because I think Java lost a lot > of it's main benefit when generics were added. > > I recently saw compile error posted on the Java forums > where it looked like it was a compiler bug but no one was > really sure. Everyone basically threw up their hands and > gave up. It used to be that you'd have people > passionately arguing about whether the compiler was right > and trying to prove it based on the spec. Now no one even > cares to try to explain. > > So I actually think Java is dying and generics is what did > it in. But it has nothing to do with the lack of operator > overloading or verbosity. It has to do with unwarranted > complexity.
WTF, these must be pretty arrogant, dim, or lazy, people if they can't accept and figure out Javac errors; this suggests poor understanding, and lack of study of the Java language specification, and lazziness for systematic trial-and-error, until understanding dawns. Amateurs!
I strongly disagree, Generics, and Auto-boxing, make it much easier to write more readable type-safe code, however Sun should have explained the <? extends T> and <? super T> Generics wildcard rules much better, and removed the need for typed constructors e.g. for collection classes.
I applied Generics to two existing code projects, at work, this revealed/resolved some nasty type conflict bugs, and bad design, which could have caused hard to trace run-time bugs; so I have proved that Generics is quite a valuable feature.
The new for(type v : collection/array) syntax makes Generics even more useful, and mades the code far more readable, as does the @Override annotation, to tell the compiler to check method overides. I have also use the new Concurrency classes to replace unsafe (naively synchronized) collection code.
I also think that Java is very overdue for closures, and first class functions, they would make it far less painful to read/write visitors, filters, event handlers, and Runables; this could be compiler 'sugar' for anonymous inner classes, so even added to Javac, in earlier versions of Java.
Java is not dying, just some people like you can't be bothered to learn how to programme more effectively (e.g. learn patterns, design your own patterns/frameworks etc.), this sounds like slothful laziness, to busy professional developers like me! What chance do you stand with new langauges, if you can't be bother invest in Java wisdom.
BTW: I write enterprise data processing applications, and reasonably complicated JSP database reports, with backend classes, in Java 1.3, 1.4, and 1.5, I much prefer Java 1.5 for projects, because Java 1.3 and 1.4 are less readable, requires more typing, and lack useful packages, and features.
|
|