But you have to get below its skin to see why.

I believe this is true of nearly every programming language. In my experience, each has certain design concepts that must be mastered for your code to move beyond a certain stage. Sure, you can produce acceptable programs¹ after a limited amount of training, but certain skills must be acquired before you can move beyond the most trivial (or possibly even tortured) implementation.

For example, C requires a firm grounding in pointers and indirect thinking. A certain database language of my acquaintance requires you to understand the interactive product before you can effectively program it. Old fashioned assembler (of the 8086 kind) required a handle on using the registers efficiently as well as the interrupts provided by the BIOS.

We might choose various things in Perl: regexes, variable context, hashes, map, CPAN use, whatever.

That's not where I'm going with this.

I get nervous when folks criticize languages for lacking specific features or constructs--especially when I feel I understand those languages quite well. For example, some have criticized Borland Delphi (a Pascal derivative) because it doesn't support multiple inheritance (ala C++). Personally, I know that there was a great deal of internal discussion within the original development team about that very point and that a specific design choice set aside that feature for others that were deemed more appropriate. Now, we can argue the validity of that choice (if we must; I'd rather not), but my point is: Sometimes we criticize things without understanding their context.

I submit that such criticism is misplaced.

That's not to discourage healthy discussions about ways to improve a language. Those are always needed, however, I don't believe that one language is completely superior to another. They're just tools and you should use the tool most appropriate for the job. And in choosing your tool, you need to account for your needs, as wells as those of the project, the people involved, and those that'll support and maintain your program over time.

Informed comparisons are fine...however, make sure that you don't make statements that others would find odd. That is, don't say "this is how it's done" without verifying that is indeed the preferred way to do it.

To illustrate, someone once offered a talk discussing certain aspects of variable typing, as implemented in popular languages.² When discussing Pascal, he first (accurately) noted that the language stores strings in arrays of chararacters. However, he noted that the following was a problem:

var 
  str : array[ 1..20 ] of char;
endVar

begin
  str := 'Hello, World!';
end;
[download]

Why did this strike me as odd? This example is problematic, but only because the wrong data type of used. If str is declared as a string type (in Delphi and its older sibling: Turbo Pascal), it works fine. (I should've asked for clarification at the time and I regret that I didn't. It would have been instructive to know what compiler the author had been using.)

Unfortunately, I was so struck by the oddness of the example, that I lost the train of thought in the overall presentation for several minutes. The presenter's points during that time were pretty much lost to me and the presentation ended up failing to achieve its purpose. (I really should have asked for a clarification.)

So why bring this up, especially on this site and in this thread?

Simply to point out that:

• As you pointed out (and I just want to highlight that), sometimes the problem lies in how you're using the language, not in the language itself.

• Exposure to other languages is helpful and such exposure needs to be long enough to actually understand the language and why other (presumeably) intelligent people like it.

• Computer languages are just tools for getting certain jobs done. The more you know about the tool you have available to you, the better equipped you'll be to use the proper one for the task at hand. (This is, I think, something that tilly's been trying to tell us for months.)

• Skills acquired in one language frequently improve your work in others. (The optimizations you mentioned can be applied to many languages, not just Java.)

• It's natural to prefer certain languages, tools, or what-have-you. It's dangerous to disregard things you aren't familiar without first taking the time to understand them as completely as possible.

• If you're going to criticize a product, language, person, design choice, or whatever, then you had best take the time to make certain that you fully understand why the thing you're criticizing is done that way. You may find yourself pleasantly suprised.

  If you don't have the time--or inclination--to fully investigate the situation, then you really don't have the time to create an informed criticism. Sherlock Holmes is quoted as saying, "It's a capital mistake to theorize without data."

And, finally, the IE6 behavior you noted has been noticed; I believe efforts are underway to find a solution that works on as many browsers as possible.

--f

¹ - By acceptable, I means programs that do what they're supposed to do, have no unacceptable problems, and fulfill the requirements of the person who gave you the task in the first place, whether instructor, manager, author, or client.

² - Yes, I'm trying to be vague. It's an attempt to protect the original presenter, who has accomplished much. I don't want my disgreement with certain points in that single presentation to take away from his other accomplishments.