language interpreters/ interpreted languages weaknesses?

[Frank Mitchell]

[caveat: I work for Sun, but *not* in PR ...]

Blake Winton wrote in message ...
>On Thu, 2 Sep 1999 18:40:41 GMT, Paul Prescod wrote:
>>There are by now dozens of impementations of Java and your complaint is
>>with a single one (or maybe two, if you have had the same problem with
>>Internet Explorer and Netscape). Seriously this has nothing to do with
>>Java *the language*. A bad implementation of Python could do the same
>>thing.
>
>Which points out, IMHO, Java's biggest problem.
>There is no distinction between Java *the language*, Java *the VM*, Java
>*the OS*, etc...  When my MSVC++ program is slow, I know enough to blame
>the MFC, and not C++ the language, but with Java the distinction is
>blurred (purposely, by Sun, it seems).


Java the OS is called JavaOS, and apart from the implementation language and
environment has nothing to do with Java.  (Scott McNealy's pronouncements
notwithstanding.)  But, point taken: Java is really a language, a whole
bunch of libraries, and a VM/bytecode specification.

The three are, however, entangled: the bytecodes implement Java language
code much more easily than any other, as the MLj  and SmallEiffel guys can
tell you, and the library includes classes that even the VM needs, such as
String, ClassLoader, and most of the Throwable hierarchy.

IMHO, if "string" were a basic type alongside array, and the VM didn't
presume the presence of other Java classes for exceptions and the like, the
JVM would be a far more compelling platform to port to.  (Even the
inheritance restriction seems short-sighted; maybe a function-based VM with
some sort of "associative vtable" would make porting other languages to the
JVM simpler.)  But then, a general VM wasn't the problem they were trying to
solve.

Similarly, if the Java packages were strictly segregated into a small "core
cluster" and one or more domain-specific clusters (e.g. UI, networking, data
structures, etc.), and a host could advertise which clusters it supported,
the Java spec would be easier to understand, and easier to implement.  Alas,
the latter may not have been a design goal either ...

> Of course, this has nothing to do with Python, except possibly to warn
> Python to stay out of that trap.

Amen.  I like the language, but there's definite room for improvement.

Frank