On Mar 5, 4:07 pm, apple2fr...{at}gmail.com wrote:

> > I'm going to have to challenge your position that Java is a "nanny
> > language" however. Higher levels of abstraction are necessary to
> > manage higher levels of complexity. A "bloated" toolset that uses
> > human time more efficiently at the cost of machine resources is
> > clearly the more 'efficient' option, when you consider total cost.
>
> > It's also responsible for popularising many of the architectural
> > innovations of the software engineering field that had laid dormant
> > for a long time, since languages in popular use prior to that lacked
> > the expressive power to harness them. It really was the right tool at
> > the right time.
>
> Java wasn't itself innovative.
>
> It introduced nothing new to the IT industry that didn't already exist
> as part of other computing languages.
>
> In fact, I don't think there is anything in Java that isn't in either
> Smalltalk (from the 1970s!) or C++ (which it was based heavily upon).

And all three can be regarded as descendants of Simula. The innovation
is in the feature cocktail: Gosling et al recognised that a Smalltalk-
esque semantic model combined with a more familiar syntax was a good
compromise. They left out many things I'd like to have seen included,
but I can't argue with the general idea.

You'll find that there's very few new ideas in sequential programming
languages, but every now and then old ideas are re-used in novel ways.
Another example would be Ruby's "blocks" which provide a simplified
form of a functional language style closure which greatly simplifies
many collection oriented code sequences.

> I call it a nanny language because it was originally put forth as a
> simplified replacement for C++ at a time when the quality of
> programmers had dropped so far that C++ became too much for them.
> Since 1.0, it has added nearly ever "feature" that was excluded from
> the original specification and thus become just as complex as the
> language it was purported to replace.  It also never lived up to the
> "write once, run anywhere" paradigm as anyone who has ever attempted
> to write a non-trivial application will attest.

One of the lessons to learn from C (and as K&R so eloquently put it in
the 2nd edition of The C Programming Language) is that "There are real
benefits to keeping the language definition small". It's deeply ironic
that C++ shunned the existing C preprocessor as not providing any
conditional compilation capacity the compilers optimiser couldn't
replicate, then promptly added a Turing-complete templating system. A
parsimonious language definition isn't just good for the programmers
who use it, it's also good for the implementers.

I think you'll be very surprised if you compare the LOC count of a C++
compiler to a Java compiler. They really are "worlds apart" in terms
of complexity.

> Proponents will point to the Java libraries as representing a lot of
> power of the platform, but I can just as easily point to the C++ Boost
> libraries as representing equivalent power with C++.

> And the idea that Java runs just as fast and with just as small a
> memory footprint as C++ has not withstood the test of time.
> Similarly, the idea that because of the built-in garbage collection,
> that Java programs don't have memory leaks has also proven false.

The reduction in code complexity by using automatic collection however
is a huge benefit to productivity. Consider also that an piece of code
doing it's own collection manually will run more slowly than code that
doesn't, and delegates it to another process that runs in parallel.

Also consider the advantages of being able to make optimisation
decisions at runtime vs. compile time. Something your compiler decided
to inline might run beautifully on your machine, but cache-thrash
really badly on your customers smaller system.

In the end, the factors influencing which horse is better are far more
complex than which one produces the most space/time efficient piece of
code.

> But were are getting more than a bit off-topic here since I don't
> think there have ever been any Java interpreters for the Apple II.

Ah but there is! Check out Dave's VM02. No compiler yet, but it's
doable. OTOH, implementing either C++ or Smalltalk on an Apple II is
for all intents and purposes impossible.

Matt
--- SBBSecho 2.12-Win32