From: Paul Fernhout <firstname.lastname@example.org>
Sorry I said anything...
Language choice is an important issue for the design of a DKR/OHS if the
system is to be extensible, although I would say APIs, communication
methods, and data storage formats (XML?) are more important.
The advantages you cite for Java are sort of half-truths.
See for some more details: http://www.whysmalltalk.com/
But in short to address the specific points you raise:
* Java's native types complicate and slow the VM, garbage collection,
and application design (is it an object or is it native?), and provide
little benefits over application specific use of memory and plugins in
languages like Smalltalk or Python for numerical intensive things like
array processing. Native types also make Java harder to learn and use
* Real world interfaces in Smalltalk are fairly easily done as plugins,
calling C code, doing socket communications to C processes, or as VM
* Yes the fact that C & C++ have a macro preprocessor make them terrible
languages for dynamic development (because a macro change in a header
file might change any code). However many other languages besides Java
(including Smalltalk and Lisp) have a more sensible approach to this or
never had the problem in the first place.
* Casts are ugly, cause brittle code, cause failures in reuseability of
code, require awkward work arounds, and have other problems. In short, I
can elegantly express a reuseable algorithm in Smalltalk, Lisp, or
Python -- in a typed language like Java, one is usually writing
application specific (cast) code or reworking such for new
applications. Ugly code is bad code -- since in the long term >80% of
time spent with code is spent either understanding it or maintaining it.
Sorry to strongly disagree, but Java is yet another example of
reinventing the wheel poorly. In another couple of years Java may settle
down, but it will always have architectural problems if it is to remain
somewhat backwardly compatible (native types, enforced exception
handling, lack of true blocks). Sun years ago wanted to use VisualWorks
Smalltalk in their set top boxes, but the Smalltalk vendor they
approached (ParcPlace) was too greedy and wanted too high runtime fees
(the same reason our product are in Delphi and not VisualWorks). So Oak
(renamed later to Java) was pressed into service, and brilliantly
marketed. A sad story -- all too common in computing.
Smalltalk was invented almost thirty years ago and has stood the test of
time. There is nothing really innovative about Java beyond marketing and
early placement in web browsers. Sun produces some great innovations --
Java just isn't one of them. Other Sun language projects had and have
much more promise. Examples are TCL because it is so simple (everything
is a string), and Self
because it is so elegant (everything is a prototype). Java does have
some good points, like an attempt at security and an attempt at object
interfaces -- both attempts fail, but there are some good ideas there.
If Sun wanted to support a ODH/DKR effort in "Self", I'd be cheerleading
all the way!
I don't think I am going to sway many people to consider Smalltalk, Lisp
or Python for their OHS/DKR efforts because the reason people use most
languages involve commercial politics, knowledge of the language, and
availability of the tools. If you're good at Java, go for it. I'm doing
most of my work related to an OHS/DKR in Squeak Smalltalk
http://www.squeak.org and Python (and to a lesser extent C-ish C++).
However, I could also make a good case for some version of Lisp as a
better choice, especially if speed matters as well written Lisp compiles
Feel free to reply publicly if you wish, but I'll make any of my
follow-ups on this topic private to you to avoid dragging down the list.
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
Eric Armstrong wrote:
> From: Eric Armstrong <email@example.com>
> Paul Fernhout wrote:
> > Smalltalk is far more efficient. Java and C++ are still wrestling with
> > solutions to problems that Smalltalk solved optimally a decade ago.
> > Just
> > one example -- modern Smalltalk VMs see practically no overhead from
> > method lookup because they cache the last used selector lookup for an
> > object. This handles 95% of such selector usages.
> SmallTalk did indeed solve a number of issues. It also left a number
> of issues unsolved. Although they break the pure O-O paradigm,
> Java's native types provide important computational performance
> benefits. They also provide for natural interfaces to real world I/O
> devices. In general, Java's static typing provides both efficient
> performance and compile-time error detection, both of which are
> highly beneficial. Finally, in what appears in hindsight as a stroke of
> genius, it's insistence on the elimination of macros and conditional
> compilations has produced a language that is easily readable -- if
> you know the language, you can read any application written in it,
> unlike many of it's predecessor languages.
> As indicated in my followup message, purely dynamic method
> invocation isn't totally necessary, either, given the ability to cast
> an object to an expected type. Some of the code is going to
> look pretty ugly with that solution, though.
MAXIMIZE YOUR CARD, MINIMIZE YOUR RATE!
Get a NextCard Visa, in 30 seconds! Get rates as low as
0.0% Intro or 9.9% Fixed APR and no hidden fees.
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Mon Mar 20 2000 - 18:48:27 PST