I haven't complained about imports.

I have complained that Java's standard library is dumb as fuck.

The point which you have missed completely. Probably because, I get the feeling, you have never used any other programming language and you simply can't imagine how it can be any different, least better.

You mean auto-complete in Eclipse can write programs for me? It would read my mind and output proper working Java code, with all the boilerplate, configuration and 3rd party libraries includes?? Would it also by chance deploy to customers too? and provide support and updates? What is the keyboard short-cut to all this magic?

The Eclipse seems have made an enormous leaps in functionality - and all that in the 6 hours since I left the office. ;)

You have completely missed the point.

When you program in Python (the language I btw actively hate; Perl guy here) it actually feels like you programming in a high level language. It gives you the tools you need to accomplish the task. Not every tool, not for every task - but the tools cover a lot of ground.

When you program in Java, it sometimes feels like you are programming in assembler: the same level of attention to details, the same microscopic impact of every line you write. And you too need to write a lot of lines to accomplish the same, other languages allow you to do in one or two lines.

I have no idea what "Red Sox" are, but Java's verbosity (and its long/shot term consequences) are universally known among software developers. It's not like Java is the first language of the kind.

Verbosity wouldn't have been so much of a problem, if the standard library was at least OK. But it is not.

Sun (and now Oracle) pretty much openly stated that they do not want to expand standard library. Main reason I heard was the security updates. (As if shifting the responsibility to the 3rd party libraries anyhow alleviates the security concerns.) The end result that Java's standard library manages to be at the same time very bloated and very poor.

For example, there is still no usable String.split(). There is standard one with the regexps, but it is very slow. I work with Java rarely (at most a month per year) and I have already seen at least a dozen of hand-coded String.split() alternatives.

If only.

I have abandoned Java shortly after Java 2 SDK release precisely because it was NOT anywhere near being a "practical tool for getting work done." Later encounters over the years only reinforced my opinion.

As one Java developer described it, comparing Java to Python at task of using the proverbial "wheel" in your program. In Python, if you need the "wheel", you just "import wheel" and use it. Java too provides you with everything necessary: "import map.ore.iron", "import tools.pickaxe", "import fire.matches", plus a 3rd party class "recipe.smelt" and a measly 1-2K LOC - and voila! you have the "class Wheel" in Java too!

Weird. Works like that 100% of time in Chrome on Win7/x64.

(Which is basically why I keep IE around: the Flash player is by far the least buggy player. I also get least video tearing with the IE.)

Are you sure you can tell the difference between SD and HD video?

I was so happy when I found that HTML5 player finally can auto-switch to high-def mode when going to full-screen.

Sadly, the happy moment was short, as I have realized that Google has "fixed" the caching issue: now part of the video which was loaded in SD mode (for smaller videos on fast connection - the whole video) stays in SD mode and switch to HD mode has no effect.

So yes, HD full-screen mode now works - but is useless.

The QA track record of the Google is as appalling as it ever was. Goes to reinforce the old wisdom that the "star" developers are useless when it comes to dealing with the mundane, real world problems.

Also true for the assemblers.

Except that it might take days or weeks to step through all of it.

Except that it theoretically might take even months, if you need to debug problem related to some framework.

It's not. Unless it is relatively small and independent application. But in that case, literally every language is easy to debug. Even C.

Yes, I understood. And I way saying, yes, it seems clear that we would all care more if it were a problem with RAID 5.

I understand that you think "we would respond differently if this were RAID 5" is a sign of hypocrisy or something. But it's not really that.

It's a little like saying, "There was a design flaw in trash cans that cause items stored in the trash can to be damaged." And people respond by saying, "Yeah, well... that's not great, but it could be worse. Things stored in trash cans are usually things nobody cares about anyway."

And then you say, "Would you respond differently if this trash can problem were discovered in long-term storage bins?"

And so the response is, "Yes, we would care more about that. Of course we would all care more about that. Because people probably care about things in long-term storage bins, and usually put trash in trash cans. I understand that someone somewhere may be storing their valuable family heirlooms in trash cans, but they probably shouldn't be doing that."

I think you missed my point. I don't doubt such people exist. I doubt such people are generally safeguarding information that I think is important.

Yes. Billing systems.

In a way, the experience is a confirmation of the RTFA. When newhires come, everybody is in the awe of the Java part, and everybody is terrified of the C/C++ part. But the thing is, a year later most change their opinion. Java might look beautiful - but the beauty is skin deep. We have had clients changing project design and architecture because developers were throwing in a white flag: they simply couldn't fix something in the Java part, and the workaround had to be put somewhere else.

With the C/C++, the usual problems tend to keep the development down to the ground. While with the Java, developers very often succumb to the fancy of implementing all the fancy things people on the internet are so fancy about. Like for example the good design practices. No, no, no - only the best design practices! Because that's how it supposed to be!! End result are the huge monstrosities, which are more compliant with the programming books than with the customer requirements.

The saddest part is that good Java pros are acutely aware of the problem. But one can't just swim against the tide.