RE: [unrev-II] Digest Number 69: Paul, Eric, Java, Python

From: John \ (johnwerneken@netzero.net)
Date: Thu Mar 23 2000 - 00:33:05 PST

  • Next message: Henry van Eyken: "Re: [unrev-II] Unrev Site V3"

    From: "John \"sb\" Werneken" <johnwerneken@netzero.net>

    Hope to see more of your discussion. I think it helps the list some.

    So far you're at the outer limits of what I can follow (not being a computer
    person) so maybe I'm learning something!

    I have heard that Python has an astronomical adoption rate. I have never
    heard anything good about the reality (not the yet-to-be-seen promise) of
    Java, other than ubiquity.

    Oh well what do I know (not much). But if this thread keeps going, maybe I
    will come to know more! Please keep it up!

    ____________
    >
    > Message: 6
    > Date: Mon, 20 Mar 2000 20:35:57 -0800
    > From: Eric Armstrong <eric.armstrong@eng.sun.com>
    > Subject: Re: Re: An Extensibility Architecture
    >
    > 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
    > Java.
    > * 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
    > spiral.
    >
    > 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 <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.
    > > -----------------------------------------------------------------------
    > >
    > > -----------------------------------------------------------------------
    > > 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
    >
    >
    >
    > __________________________________________________________________
    > _____________
    > __________________________________________________________________
    > _____________
    >
    >
    >
    >

    ------------------------------------------------------------------------
    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/_/953800169/
    ------------------------------------------------------------------------

    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 : Thu Mar 23 2000 - 00:36:42 PST