Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.duke.edu!eff!news.kei.com!world!news.bu.edu!gw1.att.com!nntpa!ssbunews!ssbunews.ih.att.com!lgm
From: lgm@polaris.ih.att.com (Lawrence G. Mayka)
Subject: Re: C++ Productivity
In-Reply-To: jsutherland@BIX.com's message of Wed, 15 Feb 1995 12:22:04
Message-ID: <LGM.95Feb26150506@polaris.ih.att.com>
Sender: news@ssbunews.ih.att.com (Netnews Administration)
Nntp-Posting-Host: polaris.ih.att.com
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
References: <D3zrpn.Hxq@research.att.com> <3htf7i$psa@news1.delphi.com>
Date: Sun, 26 Feb 1995 21:05:06 GMT
Lines: 24

In article <3htf7i$psa@news1.delphi.com> jsutherland@BIX.com (Jeff Sutherland) writes:

   We build our compiler technology in C++.  Tools are built in a combination
   of C++ and Smalltalk.  Applications are all built in Smalltalk.  This seems
   like a pretty obvious way to do things and is analogous to the
   assembler/C/COBOL mix seen in most large legacy applications.

The problem with this approach is that it ill-fits the frequent desire
of companies both small and large to "standardize" on One True
Language That Solves All the World's Problems.  If you say that
Smalltalk is not realistically appropriate for compilers or other
systems programming, you have essentially ruled yourself out.  At
least one other very-high-level programming language (which I won't
name in this newsgroup) can indeed demonstrate ample capability for
most systems programming, but it, too, has difficulty answering the
perennial question: "Is your language suitable for toasters and
microwave ovens with 4 KB of RAM?"  The lowest-common-denominator
effect is difficult to overcome.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.
