On Mar 5, 9:35=A0pm, apple2fr...{at}gmail.com wrote:
> On Mar 5, 3:18=A0pm, mdj  wrote:> On Mar
5, 4:07 pm, a=
pple2fr...{at}gmail.com wrote:
> > > Java wasn't itself innovative.
>
> > > It introduced nothing new to the IT industry that didn't already exis=
t
> > > 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. =A0It 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.

I think you're confusing the intended audience with the design ethos.
As a language,  Java owes far more to Objective-C than it does to C++.
In fact the C++ isms in the language are entirely limited to syntactic
sugar. OTOH, the underlying semantic model is almost *exactly* the
same as the NeXT extended Objective-C.

> 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. =A0My own experience is
> necessarily limited, but it supports his assertions.

I write Python as my day job. The one thing I'll give it, is that you
never again have to read badly formatted code, since indentation is
used as the block delimiter instead of language symbols.

> > 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. =A0Perl 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. =A0And yes, this is just a personal
> aesthetic problem of my own, nothing against either Ruby or Perl.

:-) I completely agree with your sentiments on 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 th=
e
> > > "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."

There's a couple of features they added back that they took from C
(variable argument lists and enumerations), but nothing of consequence
from C++. In fact, the C++ isms that are left out are the very thing
that makes it a successful language, IMO.

> > 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. =A0However, I would be
> surprised to see more than a 2-4x difference in terms of line count.

In reality, a Java compiler isn't much more than a simple tokeniser/
parser. All the heavy lifting is done by the VM.

> > > 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++ Boos=
t
> > > 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. =A0Since Java doesn't
> specify exactly when garbage collection may occur, this can cause
> execution delays at inconvenient times -- something easily programmed
> around in C++. =A0Also, as I mentioned earlier, the C++ Boost library
> contains a robust garbage collector if that is your thing.

This hasn't been true for years. See my other post on the topic.

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

Of course, this overlooks the fact that there's ways to express
problems in Java for which there's no C++ equivalent :-)

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

Agreed. And it's the primary reason I now work in a shop that uses
Python and Ruby.

> If your metric is how many platforms will it run on, C/C++ generally
> beat out Java. =A0If 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).

Actually, I'd bet the platform coverage is actually almost the same at
this point, assuming we limit the definition of platform to currently
commercially viable ones. The exception obviously is the iPhone, but
that's a political barrier, not a technical one.

> > > 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. =A0It was, after all,
> designed by Alan Kay in the early 1970s, so I doubt it needs that many
> computing resources to run. =A0Another interesting project to add to the
> queue. =A0Hardware first though...

Oh, you'd get the language on there alright. You'd run out of symbol
space before developing anything more than a demonstration that it
works, and the execution speed would be truly awful.

Matt
--- SBBSecho 2.12-Win32