response 105 of 113:

Apr 18 01:23 UTC 2006

That's true, but what I'm trying to point out is that a lot of the
`improvements' that have been made to Java are to make up for defenciencies
in the initial language design.  Some of these changes are clunky.  Consider
the following, added in Java 1.5:

        public void manipulate_things(Collection<Thing> things) {
                for (Thing thing : things) {
                        thing.manipulate();
                }
        }

This is equivalent to the following:

        // Note how in Java before 1.5, I couldn't use generics, so there
        // wasn't any type checking on what was in things....
        public void manipulate_things(Collection things) {
                Iterator i = things.iterator();
                while (i.hasNext()) {
                        Thing thing = i.next();
                        thing.manipulate();
                }
        }

Well.  The former is certainly prettier (and safer) than the latter, but now I
have this syntax (for (Thing thing : things)) that's built into the language
but relies on an interface provided by a library.  Not a good separation of
functionality, and the language and library are no longer orthogonal.

Other languages tend to do better (for instance, Ruby's blocks do away with
the need for a generalized for loop at all - the resultant code is often much,
much cleaner).

And Collections only work on objects, not primitive types.  How do I have a
List of int's?  I don't; I've got to wrap primitives in object types.  Java
1.5 makes this a little more transparent by supporting autoboxing, but it's
still a bit clunky; there was some ambiguity around what happens when you try
to unbox a null reference, for instance (and indeed, what *should* happen
there?).  So, now as I iterate over a list of ints, I have to check for null
ints, which is very much non-intuitive.  At least with C++, std::set<int> does
something sensible.

Now, like I said, I think Java does a bit better than a lot of its peers.
Overall, for instance, I'd say it's a better language than C++ (just try
putting a polymorphic type into a generic container without using pointers,
contrast Java's references!).  But that doesn't make it a great language.  Is
it improving?  Perhaps; I think some of the `improvements' are debatable.  For
instance, maybe the Collections issues would have been solved more elegantly
with the Ruby approach of blocks and iterators.  I would argue that a lot of
the improvements are necessary because the designers didn't think through some
of their choices when they were designing the language in the first place.  In
particular, the split type system and lack of something like generics in the
beginning have been persistent sources of headaches.  Reviewing other
languages like smalltalk and Eiffel (both of which predate Java by a fair
bit) may have eliminated some of these issues.

response 107 of 113:

Apr 18 13:02 UTC 2006

Right.  But I was responding to your assertion that my statement that Java
wasn't *great* was due to my inexperiene with it, Mic.

response 109 of 113:

Apr 18 20:21 UTC 2006

Thanks, Mike, that accurately summarizes what I was trying to get across.

response 111 of 113:

Apr 18 20:52 UTC 2006

I'm Java incaffeinated, Mike/Dan - which is partly the bias.  
Assert.booleanEquals("That was part of what I was saying") ---> true
Assert.booleanEquals("Wasn't trying to infer Dan was Java incompetent, by 
any means") ---> 1 == 1

response 113 of 113:

May 17 02:16 UTC 2006

TROGG IS DAVID BLAINE