Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!haven.umd.edu!news.umbc.edu!eff!news.duke.edu!news.mathworks.com!newsfeed.internetmci.com!uwm.edu!reuter.cse.ogi.edu!qiclab.scn.rain.com!slc.com!servio!servio!aland
From: aland@servio.slc.com (Alan Darlington)
Subject: Prototype VS Production  (was Re: Why do you hate C++ ?)
Message-ID: <1995Dec29.203458.19719@slc.com>
Sender: news@slc.com (USENET News)
Nntp-Posting-Host: servio
Organization: GemStone Systems, Inc., Beaverton OR, USA
References: <4bspq6$1ah@parody.tecc.co.uk> <4buaue$e2h@sundog.tiac.net> <4bvdno$1h5@parody.tecc.co.uk>
Date: Fri, 29 Dec 1995 20:34:58 GMT
Lines: 52

james@parody.tecc.co.uk (James Raynard) writes:
<snip> 
> Anyway, I usually think of Smalltalk as being best suited to a prototyping 
> environment rather than a production one (at least that's the impression
> I've got so far), so our views probably aren't as far apart as they might
> appear.
<snip> 

I wish to express the opposite opinion.  After 11 years of working with
Smalltalk (mostly on 3 different commercial applications), I now believe
that Smalltalk is a very good production environment for the following
reasons:

  (1)  The number of lines of code (or function points, or whatever)
       seems to be about an order of magnitude smaller for applications
       written in Smalltalk (as compared with C++, say).  This means
       fewer programmers, usually resulting in better integration and
       less problems.  (See _Software Productivity Research_ by Capers
       Jones, http://www.spr.com/library/langtbl.htm.)

  (2)  Performance is usually better.  (Yes, I can feel the ground
       trembling...  :-).  Smalltalk has good performance measurement
       tools (thank you, Kent).  With the smaller amount of code in
       your application, you can actually afford to use these tools
       and rewrite your algorithms to get orders-of-magnitude improve-
       ment.  (You may even have time to export critical pieces of
       _tuned_ code into Fortran, C, C++, or assembler, wherever they
       happen to belong.)

  (3)  Changes are easier and faster.  In today's competitive business
       environment, waiting 2 or 3 years for a change to an enterprise-
       wide business application is a killer.  These days, just about
       any application is an evolving prototype for its entire life
       (or is left in the dust...  :-)

  (4)  Who cares about memory / disk / processor costs?!?  (Wow - I can
       feel a volcano erupting now!)  One of our customers is using a
       server with 2 GigaByes of main memory!  (I just upgraded to 3 GB
       of _disk_ on my home computer - sigh.)  This stuff is so cheap
       compared to human costs (not to mention the cost of getting an
       application out 2 years after the competition) that anyone
       fighting against hardware upgrades is (IMVHO) crazy.

I realize that much of this is opinion and controversial.  (I can feel
the heat already.)  But after 30 years in this business, I feel entitled
to at least a few opinions!  :-)

Contrary viewpoints welcomed - I look forward to reading them!

  Cheers,
  Alan
    (standard disclaimer)
