Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!mcnc!nowhere!rick
From: rick@cua.cary.ibm.com (Rick DeNatale)
Newsgroups: comp.object
Subject: Re: The Emperor Strikes Lethe
Message-ID: <1991Apr12.144951.13507@cua.cary.ibm.com>
Date: 12 Apr 91 14:49:51 GMT
References: <43.UUL1.3#913@acw.UUCP> <890@puck.mrcu>
Sender: rick@cua.cary.ibm.com.UUCP (Rick DeNatale)
Reply-To: rick@cua.cary.ibm.com.UUCP (Rick DeNatale)
Organization: CUA
Lines: 46

In article <890@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes:
>
>No, not even in theory.  We knew that.  So what?  Most languages
>(interpreted ones such as Smalltalk mostly excepted) have C language
>interfaces).  If you REALLY need to do it, you can build wrappers
>around the modules in the other language and carry on from there.  If
>you have a class library in a given language and want to enhance it,
>it is better to do it in that language.
>
>Of course, you can always use the existing libraries in other
>languages via C language interfaces, although it is certainly not easy
>or clean.  How is this worse that existing systems?  Ever tried using
>X from Pascal?
...
>...  Smalltalk is an interpreted language for
>prototyping, so this is not a problem.  

Remember, there aren't such things as interpreted languages, or compiled
languages.  There are implementations of most languages (Smalltalk included)
using both techniques.  Digitalk's Smalltalk/V PM for example, is a fully
compiled (yes Virginia, it does generate machine code directly from your
source) implementation.  Smalltalk/V for windows compiles to byte codes which
are interpreted (as do the other flavors of Digitalk Smalltalk).  ParcPlace
uses a hybrid dynamic compilation technique which caches dynamically compiled
machine code to trade off a little speed for space.

As far as C language interfaces, Digitalk provides a very nice and easy to
use C interface in both Smalltalk/V PM and Smalltalk/V Windows.  So even this
isn't an issue of compilers vs. interpreters.

Finally, yes, conventional wisdom is that Smalltalk is for prototyping, but
as Scott Knaster so nicely pointed out "conventional wisdom is often wrong."
Smalltalk has been used for production and commercial software.  If you ever
get a chance to hear someone like Dave Thomas of Object Technology Inc., or
Reed Phillips of Knowledge Systems Corporation speak about their experiences
with using Smalltalk in the real world, I'd recommend it.  Dave gives a good
talk that is often titled "You can't do that with Smalltalk".  Reed has had
several experiences where "prototypes" went into production after  a KSC
client had mistaken beliefs about performance, robustness, or something else
that goes bump in the night corrected.

Smalltalk has certainly had to overcome as much mythology based on its early
implementations as Eiffel has.

Rick DeNatale
Of course my opinions are my own, who else would want them?