Somewhere between a third and half of these complaints have been addressed as of Java 6, sometimes at not inconsiderable cost (generics, for example). But most of the fundamental complaints--handling unboxed data, the need to constantly wrap data, the brittle standard libraries, the sheer irritation of using anonymous inner classes for closures--are all things I trip up against every damned day.
Besides being vastly outdated, this article suggests that Java is on par with Perl when it comes to performance. In fact, Java is almost as fast as C++ on most computational tasks, and faster than most other languages (http://shootout.alioth.debian.org/)
But why do java applications tend to be these huge, clunky, slow and memory hungry applications over and over and over again? Eclipse, any J2ME application/server and so on. Working on java applications has always been pain.
Vastly outdated? Really? It's been quite a while since I've used Java so I'm curious to find out:
Does Java have lexically scoped functions now? Macros? Inlined functions?
Does Java have closures now?
:keywords?
CLOS-style multi-dispatch?
It's not like there weren't languages out there, that certain co-authors of the Java spec did their PhD and postdoctoral work on, that implemented all of these features...
Actually, there is. If you try to submit an URL that has already been posted, then you upvote the original submission. But it seems there's some sort of expiry after which reposting the URL creates a new submission.
Also, sometimes there's problems when 2 different URLs point to the same article.
While he makes the point that Java was 4 separate things that should've been developed and released separately, that probably would have seriously hindered adoption and even caused the language to die. [In hindsight, maybe that would have been best. >:)]
When I first started with Java years ago, one of the things that made it appealing to learn a new language was the fact that it came with a box of toys (such as easily-constructed graphics contexts, UI elements, and threads). In the days of Java 1.0, it was probably the quickest way to get fairly sophisticated things up and running, so that power made it all worth learning. Had it just been some research language with no libraries or JVM, I probably would've said "great, but...what can I do with it, nothing!".
In my case, this still came full circle; I eventually decided I really hated Java for any serious programming. I never choose to use Java for anything these days, I only put up with it if I'm maintaining something that is already Java-based.
The forced unicode String complaint is quite valid. Implementing any sort of large in-memory index in Java basically requires a parallel implementation of String (not actually 'implements String') to keep its memory usage down to a reasonable level. Unless of course you're actually indexing Unicode strings.
With many other languages Unicode is some afterthought. Ever tried Unicode things in php? It's horrible.
Having all strings as Unicode is fantastic. If you're dealing with something else and can't afford the memory, then sure - roll your own with byte[] arrays. Not a big deal.
I use unicode in php routinely. It works fine. If you need sub-string manipulations add mb_ to stuff (and if you are manipulating an entire string you need do nothing special).
And if adding mb_ is too much trouble use mbstring.func_overload.
UTF-8 only of course. All the other encodings should never be used anywhere. With UTF-8 the majority of the time you can use regular functions - for example trim() works just fine on a UTF-8 string.
I'm curious why Java doesn't use UTF-8 encoding by default; that would offer much of the memory savings the parent poster is talking about, if the data is mostly ASCII anyway.
How "extreme" are we talking about? Some empirical data would be helpful.
I'd also be curious to see data about what % of the characters in all the strings in a typical Java program aren't in 7-bit ASCII. I wouldn't be surprised if 7-bit ASCII characters are a large majority of the total, which makes the case for UTF-16 less compelling.
I've been countless hit by programs crashing because I'm using an accented character. It is really easy to think "I'm not using unicode strings there"... until an user uses unicode characters.
Enforcing unicode is a good thing, whatever english speakers could think about.
It may be old, but he raises some good points. Java's syntax is probably a step forward from C++, but both are still far from intuitive.
In an ideal world, I'd love to see a pared down version of Java's syntax matched with a better-optimized version of GCJ - the readability of Java combined with the speed of native bytecode would be a godsend.
I don't think you're right that the people behind Java didn't understand languages. There are actually a lot of things which Java gets right. For instance, Java's namespacing is very good.
Unfortunately, being smart and knowledgeable isn't enough to build a good language. A language has to "fit together" in a way that just can't be forced. This is why Java, whose design is pretty intelligent, is absolutely miserable to work in; while Perl, whose design is random and crufty by comparison, can be easy to work in and highly productive.
