Re: [unrev-II] Re: An Extensibility Architecture

From: Paul Fernhout (pdfernhout@kurtz-fernhout.com)
Date: Mon Mar 20 2000 - 18:41:52 PST

  • Next message: Peter P. Yim: "[unrev-II] [Fwd: Red Herring] - Article on the Colloquium"

    From: Paul Fernhout <pdfernhout@kurtz-fernhout.com>

    Eric -

    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
    well. See:
      http://www7.software.ibm.com/vad.nsf/Data/Document2712
    * Real world interfaces in Smalltalk are fairly easily done as plugins,
    calling C code, doing socket communications to C processes, or as VM
    extensions.
    * 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
    http://cora.jprc.com/cgi-bin/details.cgi?id=10516&from=hier_html.cgi
    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
    well.

    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.

    -Paul Fernhout
    Kurtz-Fernhout Software
    =========================================================
    Developers of custom software and educational simulations
    Creators of the Garden with Insight(TM) garden simulator
    http://www.kurtz-fernhout.com

    Eric Armstrong wrote:
    >
    > From: Eric Armstrong <eric.armstrong@eng.sun.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.
    Apply NOW!
    http://click.egroups.com/1/2122/3/_/444287/_/953606471/
    ------------------------------------------------------------------------

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe: unrev-II-subscribe@onelist.com
      Unsubscribe: unrev-II-unsubscribe@onelist.com
      List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page:
      http://www.onelist.com/community/unrev-II



    This archive was generated by hypermail 2b29 : Mon Mar 20 2000 - 18:48:27 PST