Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!zaphod.mps.ohio-state.edu!wuarchive!m.cs.uiuc.edu!cs.uiuc.EDU!johnson
From: johnson@cs.uiuc.EDU (Ralph Johnson)
Newsgroups: comp.object
Subject: Re: Syntax Change Not Paradigm Shift
Message-ID: <1991Apr16.190044.8567@m.cs.uiuc.edu>
Date: 16 Apr 91 19:00:44 GMT
References: <47.UUL1.3#913@acw.com>
Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager))
Reply-To: johnson@cs.uiuc.EDU (Ralph Johnson)
Organization: University of Illinois
Lines: 26
Nntp-Posting-Host: m.cs.uiuc.edu

In article <47.UUL1.3#913@acw.com>, scott@acw.com (Scott Guthery) writes:

After claiming that most class libraries are just reimplementations
of the same old thing ...

|> In the commercial realm where real computing is done and where the vast
|> majority of both the cycles and the dollars of computing are found, one
|> doesn't find this mindless pursuit of endless transliteration.  COBOL is
|> sufficient and has been for years.  There is, you see, a real job to get
|> done.

This is not true.  Most COBOL programs are just reimplementing what has
been done hundreds of times before.  Most COBOL programs are the usual
accounting, inventory, and personel programs.  For some reason, existing
software never seems to be quite good enough, COBOL programmers prefer
to write their own.  That's not completely true; one of my friends is
a customizer of a large personel program for universities, and he goes
from one school to another customizing it.  Thus, a number of schools
bought the package instead of building their own.  However, most COBOL
programmers write the same sort of programs over and over.

Class libraries for data structures are not really a good example of
the power of object-oriented programming.  However, they are simple and
easy to implement, so lots of people do.  A much better example is
user interface systems, in particular the frameworks for drawing editors
like Unidraw (part of InterViews).