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

From: Eric Armstrong (
Date: Mon Mar 20 2000 - 20:35:57 PST

  • Next message: Jon Winters: "[unrev-II] Article: Why The Future Doesn't Need Us..."

    From: Eric Armstrong <>

    Paul, I really wish I could disagree with you. I just can't.
    I agree with most every argument you made -- especially
    the points about native types. After learning some 20 languages,
    I'm *still* on the prowl for a really, really good one.

    What got me into the Java camp:
      * As you say, good marketing. That has produced something
         of a standard. And that is valuable. In the last 10 years, the
         computing world has finally woken up to the fact that standards
         are our most important product.
      * That said, I would love something friendlier to program in.
         I suspect that the Java virtual machine will be the lingering
         legacy, long after an even better language has supplanted
      * From what I saw of SmallTalk, it was really limited in terms
         of real world interfaces. At this point, the multimedia
         interfaces are built in with Java 1.3. There's not a whole lot
         you can't do --easily, because the hard work of writing the
         adapters has already been done.
      * Benefits of "open source". If it ain't really, there was a ton
         of code invested by IBM and others that made for really
         big libraries.
      * GUI widgets. The Swing toolset provides not only enormous
         functionality -- but functionality which is a standard part of
         the platform (and which therefore does not have to be shipped).

    Again, it's a "tipping scales" argument. There is a lot of code out
    there because so much was invested in it, which occurred because
    there were so many adopters, which came from so much marketing
    (plus real benefits), all of which is gorgeously self-perpetuating

    What I've seen of Python looks *really* interesting. And SmallTalk
    is decidely elegant. I can't blame you a bit for gravitating towards
    those languages. Interestingly, though, SmallTalk defeated my
    efforts to penetrate it -- most notably because of the lack of native
    types. As an "old school" programmer, I felt really comfortable
    with Java's native types, which made it *possible* to transition into
    the world of O-O thinking. (Once having made that transition,
    however, I recognize how much damage they do to the elegance
    and adaptability of applications. I wish it had been possible to
    make the leap without them. I left a trail of bread crumbs for
    taking people in O-O thinking in my book, The JBuilder 2 Bible.
    At some point, it would be interesting to revisit the strategems I
    employed there on behalf of SmallTalk or Python.)

    So, hopefully by now you will have countered the arguments I
    made above, and we can take a serious look at SmallTalk and/or
    Python as an implementation vehicle!

    Paul Fernhout wrote:

    > From: Paul Fernhout <>
    > 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:
    > 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:
    > * 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
    > 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
    > 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
    > Eric Armstrong wrote:
    > >
    > > From: Eric Armstrong <>
    > >
    > > 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.
    > -----------------------------------------------------------------------
    > -----------------------------------------------------------------------
    > Community email addresses:
    > Post message:
    > Subscribe:
    > Unsubscribe:
    > List owner:
    > Shortcut URL to this page:

    GET A NEXTCARD VISA, in 30 seconds! Get rates as low as 2.9%
    Intro or 9.9% Fixed APR and no hidden fees. Apply NOW!

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    This archive was generated by hypermail 2b29 : Mon Mar 20 2000 - 20:43:14 PST