> From: thant@disney.com (Thant Tessman)
> Newsgroups: comp.lang.c++,comp.object,comp.lang.misc,comp.lang.scheme
> Date: 27 Dec 1994 20:33:44 GMT
> Organization: WDI
> NNTP-Posting-Host: ahclem.rd.wdi.disney.com

> In article <3dc3mm$176@Starbase.NeoSoft.COM>,
> claird@Starbase.NeoSoft.COM writes:

> > In fact, should someone wish to
> > turn this thread in a productive direction, I'd
> > welcome specific examples of effective ways to
> > talk about Eiffel and/or Smalltalk with manage-
> > ment and junior programmers.  Thant?  Anyone?
> > *That*'s where the real challenge lies, at least
> > in my part of the commercial world.

> Our project uses a combination of Scheme and C++.  We use C++ in the
> speed critical parts of our application (and in general any place C is
> appropriate), and we use Chez Scheme as the scripting/extension
> language.  (There's much more to it but I don't think I'm supposed to
> be describing the architecture in too much detail.)

> I was lucky.  I didn't have to convince "management" of the advantages
> of Scheme.  I only had to convince the technical lead who, luckily, is
> a very smart guy.  It was fairly obvious to him that Scheme was the
> only way we were going to get anything reasonable done in any
> reasonable amount of time.

> We were initially *very* concerned about using Scheme in a real-time
> application both because of its speed and because Scheme does garbage
> collections.  We devised all sorts of alternate emergency backup plans
> in case Scheme didn't work out.  As it turns out, the amount of time
> our application spends in Scheme is not that big, and, to our great
> relief, garbage collection (at least in Chez Scheme) was fast enough
> to be a complete non-issue.

> ***

> Why we were able to use Scheme:

> The scheme we eventually chose was a commercially supported product
> which was robust and fast and it had a good chance of being around for
> a while.

> We were not concerned with software market conditions (beyond what I
> said above).  We had no intention of selling it to anybody, or making
> it work on every platform on the planet.  We just had to get it
> working.

> To our knowledge, much of what we were doing had never been done
> before.  Or at least there were many parts of our system that we
> couldn't buy from other folks.

> ***

> When we are working on the Scheme side of our system, there isn't a
> week that doesn't go by where somebody on the team doesn't
> spontaneously erupt with "Scheme is cool."  When we are working on the
> C++ side of our application, there isn't a week that doesn't go by
> when somebody doesn't vehemently spout "C++ sucks!"

> Programming in C++ is so painful we constantly think about ways of
> moving more of the application out of the C++ side.  It's irrelevant
> at this point, but if I had a chance to do it over, I'd seriously
> consider a few other languages in order to avoid using C++ as much as
> possible.  SML and Dylan are my favorites.  There are other problems,
> but the main problem with SML is that it doesn't provide a good
> foreign function interface.  The main problem with Dylan is that it
> doesn't exist.  And neither language can hold a candle to Scheme's
> elegance and teachability.

> One more interesting note: I'm told that big financial institutions
> are always exploring advanced software development techniques.
> Apparently, they use languages like Smalltalk and Common Lisp all the
> time because they lose large amounts of money in small amounts of time
> when their software doesn't do what it needs to do.  They are also
> extremely secretive about this for obvious reasons.

> thant