response 103 of 113:

Apr 16 18:02 UTC 2006

Regarding #98; Actally, it's because I probably have *more* exposure to it and
a lot of other languages.  There are certain things in Java that are just poor
design decisions.  Among them:

1) (At least initially) lack of a well-designed standard library.
   Tell me why each new release of Java seems to reinvent basic libraries?  We
   went from AWT to Swing.  From no threads to coroutine based threads with
   monitors for concurrency.  From one set of collections to the other.
2) Why aren't `primitive' types objects?  Please don't tell me efficiency.
   But this means that you can't have a generic, object based container
   library that contains int's.  You have to wrap them in Integers.  This also
   means that arrays aren't objects; they're primitive types.  C++ made this
   mistake, and now we have to pay for it with templates.  It's interesting to
   note that smalltalk had everything as an object, and ran with good
   performance and much smaller hardware than Java ever ran on.  So it's not
   efficiency.
3) Speaking of efficiency....  Why go with a stack based VM?  That sort
   of thing just doesn't map well onto actual hardware, which is usually based
   on register machine models.  Why not go with something like the Dis virtual
   machine used in the Inferno system?  Based on a memory to memory model, the
   VM maps well onto current instruction sets.  Thus, it's easy to write a JIT
   compiler for it which gives really pretty good performance.  With Java, the
   compiler is simple (since the ``machine code'' is very similar to the ADT's
   the compiler spits out - one of the nicities of the stack based VM), but
   the JIT is rather more complex.  This makes Java code have a high startup
   cost, which is rather annoying.  I'd rather Josling et al had taken the
   middle ground that Phil and Rob did with Inferno.
4) The concurrency model is based on the 1960's style of coroutines and
   explicit mutexes.  Why not make it based on CSP?  Come on, we could have
   moved boldly into the 1980's!
5) Java has a high start up and entry cost; it discourages casual programs.
   It is difficult to write a one-off program in Java whereas it's almost
   trivial in a higher level language like Python or Ruby.

This is just a sampling of the things I think Java is imperfect on; I could go
on.  Like I said, I think Java on grex would be interesting, but I don't think
it's a great language.  Better than most of its predecessors, it failed to
learn some essential lessons from some of the better ones, and the result has
been an often inconsistent and a moving target.  The fact that they just added
a form of ``for (item in someset) { ... }'' syntax in Java 1.5 tells me they
didn't quite think it through the first time, even though a lot of other
languages have been doing similar things for a *long* time (e.g., smalltalk
and awk, which both predate Java and have similar mechanisms.  While awk
doesn't have the semantic expressiveness of the type system that Java does,
smalltalk certainly does).

Mic, please don't insult me by saying it's just because I don't know enough
about it; I've implemented enough things of sufficiently large scale that I
have some idea of what I'm talking about when it comes to language design.

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