Hacker News new | comments | show | ask | jobs | submit login

I find it entertaining that Java's apparent successor will be, in many ways, a copy-cat of modern C#. It wasn't long ago that C# was created in Java's image.

If this language is not continually enhanced, then it will fall behind. Java has always had trouble with this because of committees and fear of actually saying "no" (real deprecation). I swear "it'll be in Java 7" has nearly become a tag-line this year.




Back-compatibility is what enables old, useful, expensive applications to keep running. It is what made Microsoft so much money, and Intel so much money. It is the reason why Java is so universally adopted.

At the same time, back-compatibility is frightfully horrific. I really feel for the x86 engineers, for one thing.

And it's no protection against a true disruption - I was going to say "such as webapps and mobile", yet Java is strong on both (server-side and smart-phone). So it must be doing something right. I think it's that its depth of libraries (and tools and coders) means that you can fulfill any particular need more quickly than any other way - which is the application of programming languages. The depth of libraries is directly supported by back-compatibility (the old ones still work).

And, in this sense, it just keeps getting better and better.


The cynical in me attributes this presence of Java in enterprisey applications to the huge piles of documentation, flows, UML diagrams, the piles of servers, ESBs and Oracle databases, along with the priesthoods that keep all that in place and up to date.

Reading that pile of documentation and interviewing the hordes that tend to the application are much more work than it would take to write a more modern version of whatever that does with 1000 lines of Perl (or Ruby, or Lisp, or Python, or Erlang, or Haskell).

It's not as much as Java did something right, but more like we did too much around it.

Disclaimer: I am currently struggling with a web application that's little more than a CRUD, but done with what I call "framework bingo" on top of a complicated network of servers, with dedicated Mule feeding Elastic Search servers where a simple CRUD (even the one that comes free with Django apps) feeding a static file system would offer better throughput and easier troubleshooting than the huge pile we see there.


According to Moore (Chasm guy), new technologies tend to get standardized on by big organizations. Adopting it in the first place was hard enough, and they want to put off doing it again for as long as possible. The infrastructure and dependencies (those huge piles) are a big part of why it's hard to change. Some are important and necessary dependencies that are expensive to change no matter what. I think this is characteristic of the enterprise.

Back-compatibility facilitates this postponement of change.

I daren't be an apologist for that webapp (esp since I don't know anything about it and I agree with you anyway), but my inner contrarian pipes up with Joel's essay on rewrites (http://www.joelonsoftware.com/articles/fog0000000069.html). Though it sounds like there isn't even a grain of truth with respect to the architectural decision.


I believe this specific application can be rewritten in a week or so. If we factor in all the resources that had been dedicated to making small changes and the disproportionate amount of effort dedicated to make sure those small changes didn't break everything else, I'd go with a rewrite even if we kept the whole damn thing in Java, just with a saner architecture.


The Java people have always been very reluctant to add new features because they wanted to keep the language clean and simple, a design choice that personally I think is superior to 'rich' grammars like that of C++, Python, and C#. How many people really know and use 100% of the C++ syntax these days? Many companies actively enforce a strict subset of the language, and who even cares about C++0x? In my humble opinion C# pretty much jumped the shark when they started adding things like partial classes.

There's lots of things wrong with Java, but I think a worthy successor should at least keep that 'less is more' mentality.

If you want a feature-rich Java though, you can always try the KSL: http://openjdk.java.net/groups/compiler/ksl.html

edit: by the way, I'm not saying Java > Python, just that I prefer clean languages. Just wanted to get that out of the way before I get flamed to death :3


>because they wanted to keep the language clean and simple

If this is the goal, I'm afraid they went of course before getting out of the bay. Clean and simple is how I would describe Smalltalk, not Java. And Smalltalk a lot more concise (note: not terse).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: