[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4