On Mar 5, 3:18=A0pm, mdj  wrote:
> On Mar 5, 4:07 pm, apple2fr...{at}gmail.com wrote:
> > 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.
>
But the feature cocktail wasn't even innovative.  It simply subtracted
a lot of things (like pointers and multiple inheritance) from C++ and
added garbage collection (which is also provided by the Boost library)
and dynamic polymorphism all with the intent of creating a simpler
language for average programmers.

In fact, in an interesting article by Paul Graham (http://
www.paulgraham.com/pypar.html), he argues out that if you want good
programmers, you should hire Python programmers because they are in
general better than Java programmers.  My own experience is
necessarily limited, but it supports his assertions.

> 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.
>
Sadly, Ruby derives much of its syntax from Perl.  Perl reminds me of
the line noise I used to get on 1200 baud modems when I was connected
to mainframes way back in the day.  And yes, this is just a personal
aesthetic problem of my own, nothing against either Ruby or Perl.

> > 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. =A0It 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 don't mean to hold up C++ as an example of a good programming
language (but I would do so with Smalltalk).

It's also deeply ironic that Java added in nearly every feature they
originally took out "in the interests of making the language simpler
and more accessible to programmers."

> 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.
>
I expect the C++ compiler would be considerably more complicated owing
to the necessity of performing code optimization.  However, I would be
surprised to see more than a 2-4x difference in terms of line count.

> > 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.
>
There are pros & cons to both ways of doing it.  Since Java doesn't
specify exactly when garbage collection may occur, this can cause
execution delays at inconvenient times -- something easily programmed
around in C++.  Also, as I mentioned earlier, the C++ Boost library
contains a robust garbage collector if that is your thing.

> 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.
>
This is true in theory; however in practice I have yet to experience
any Java program running more quickly (or with less memory) than an
equivalent C++ program on any platform.

> 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.
>
I agree with you completely here.

If your metric is productivity, there are many languages which are
better than Java, of which Python is but one example.

If your metric is how many platforms will it run on, C/C++ generally
beat out Java.  If you can't get a Java runtime library for your
platform, you're out of luck when it comes to running Java programs
(unless you compile them with the gcj compiler).

> > 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.
>
Cute.

I'm betting that Smalltalk should be possible.  It was, after all,
designed by Alan Kay in the early 1970s, so I doubt it needs that many
computing resources to run.  Another interesting project to add to the
queue.  Hardware first though...

--
Apple2Freak
--- SBBSecho 2.12-Win32