(Ok...my first rant post...here goes...)
I have to say that if Java picks up JSR-308 (which I found out about from here), then you can consider me the first one to jump off the Java train.
Seriously...do we really need this in the Java language?
Now I'm a little biased toward annotations in general - I've never been a fan of them. I've always considered them to be a hack that was dumped into the Java SE platform for no other reason than to help deal with problems in Enterprise Java. Seeing this just further solidifies my longstanding discomfort with them.
Seeing code littered with little @-signs all over the damn place is going to remind me of my days looking at code that abused the C and C++ preprocessor with all those #define this and #ifdef that that would drive any sane developer straight to wherever crazy programmers go when the lose their minds.
Ugh.
There's a reason people flocked to Java in those early days: it was easy to use. None of those crazy idiosyncrasies from C++ to deal with. It was nice and simple to learn and nice and simple to use.
Now we have a bunch of people thinking we need to over complicate the language...for no understandable reason other than "just because."
First we got Generics. We all know how that went. While it's passably better than what was originally there, it's still not worth a damn. Granted, if Sun wasn't so damn worried about preserving backward compatibility we probably could have had a cleaner implementation, but it is what it is and we're stuck with it. I'm still not so sure we really needed it - my coding was getting along just fine without. Yes, all those casts were a pain in the ass, but I learned to deal with it, as did many other developers.
Now there's the whole closure debate going on. Quite frankly I'm still having a hard time trying to figure out whether the average developer is really going to make any use of it. Sure, closures are a handy thing to have, but the simple fact that the Java development segment of the industry has been chugging along for 10+ years just fine without it tells me that it's not really all that important.
There's also the fact that the Java languages wasn't designed with closures in mind to begin with, which means that whatever implementation we end up with is going to be some tacked-on hack job that's going to end up making the language even more incomprehensible than we've already managed to make it.
And I have little doubt that the implementation of closures is going to suck - especially if Sun (or whomever is in control since Java is open-sourced now) tries to maintain backward compatibility with the previous platform versions just like they did with Generics. I have zero faith in the idea that closures will get implemented in a clean way.
Now I see this annotation insanity, which isn't guaranteed to be implemented, and I'm wondering exactly who the hell comes up with some of this stuff, and why the purveyors of the Java language even allow such ideas to get consideration for inclusion in the langauge.
It's no wonder we have Rubyists singing the praises their language and regaling us with ideas like andand, looking at us Java idiots and wondering when we're going to wise up. We're turning the language into an insane pile of unusable crap.
We've somehow deluded ourselves into thinking that Java's greatest strength - it's simplicity compared to previous popular languages like C++ - is somehow a hindrance to it now, so we've decided to tack on all these other features that came from C++ and the like - features that were not included for a reason, remember - to try to "make it better." On top of that, we've got this weird language envy thing going on: We want to add all the ideas from our dynamic language friends out there and try to dress up Java and pretend it's something it's not.
Here's a tip for everyone. I can't take full credit for it: I got it from a hot rod magazine, of all places. It's as true today as it was when I first read it back in my teenage years, and just as relevant:
A universal part universally doesn't fit anything.
Java is not a universal part - it will not - and should not - work for all solutions. The sooner we stop trying to twist it into some monster super-solution that's all things to all developers the better off we all will be.
Wednesday, May 7, 2008
What Hath Java Wrought
Posted by
Brian C Cunningham
at
10:16 PM
Subscribe to:
Post Comments (Atom)
8 comments:
java was a good language compared to c++ for the same reasons svn was a good versioning system compared to CVS, because it flew over the flaws doing things right and simplifying the development process.
Not being a Java fan myself, I had to build/patch/work-with a 1.6 Java application that uses ant+apache ivy lately. ivy is very far from being usable like cpan, easy_install or gem. But that was not the issue, the once simple syntax is just overkill these days and directs you to overarchitecturing your stuff and write loads of boilerplate code. It is just not funny anymore. So to me, it is doomed to failure. Maybe, other jvm languages can mitigate that but i am not sure about it.
So if you start just adding hacks to the Java stack, nothing good can come from that
Unfortunately, there are corporations out there that think that Java is the tool for every single solution. This means that the developers are stuck implementing everything in Java when some of them realize that it would be more beneficial to code some things in a language like Python. In these cases and for these language-conscious developers, the added complexity and ugliness is a fair price to pay for some modern language features. I wouldn't mind having closures as long as I'm forced to use Java for everything. It's a choice between the wrong language and the wrong language with closures.
Ideally people would realize that Java should not be used as a universal tool, and then making it uglier and more complex wouldn't really benefit anyone. It's the monolingual programmers and managers that are the problem.
This happens to languages, but also to corporations. You don't need to be all things to all people to be successful. Take Microsoft for example.
Great post! I am %100 in agreement with you.
Unfortunately Java started as a severely crippled C++ clone and only by chance became mainstream. Arguably the only thing they should have let go was destructors (as a consequence of GC) but the infamous finalizers demonstrate that even that was not required.
Even freaking Ruby can overload operators while Java has been struggling with its bogus reincarnation of templates instead of introducing all the features required for STL.
Still, I do not see any viable alternative to Java growing from the same C++ branch. Personally I hate the idea that languages with incomprehensible syntax (e.g. Ruby) are promoted as the next big thing.
I want new features such as Erlang-style concurrency or Ruby-like blocks but only glued together with C++/Java-inspired people-friendly syntax.
Might Scala be the answer indeed?
@Nick
"Personally I hate the idea that languages with incomprehensible syntax (e.g. Ruby)"
That's like saying Chinese has incomprehensible syntax because you speak English.
IMHO, Ruby is one of the easiest OO languages to learn.
Java is a mess. I'm still recovering from a few years of J2EE.
Time heals all wounds. . .
+1 on being concerned on the scary overuse of annotations
re: generics. They are very useful, IMO. Yes the corner-cases are sharp, but I will take them.
re: stuck. Not true. Reification of generics is brewing for Java 7+
re: Closures. The argument for closures involves something that has changed in the last 10 years: multicore. Closures can simplify concurrency APIs that are on the way.
Java's anonymous classes are a poor attempt to bring closures into the language. Anyone who ever wrote a thread function or event handler for SWING knows first hand teh suffering that the absence of closures in Java can cause. This feature is long overdue.
And yes, annotations are even worse hack than anonymous classes. The Java people are attempting to implement Lisp's macros (code that operates on code, if I understand it correctly) with a compile-time Java plug-ins. With crippled feature set it's as much pain as anonymous classes, if not more.
Post a Comment