Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.c++
Subject: Re: Tools for C++
Message-ID: <77300035@p.cs.uiuc.edu>
Date: 17 Oct 89 16:40:27 GMT
References: <17974@brunix.UUCP>
Lines: 53
Nf-ID: #R:brunix.UUCP:17974:p.cs.uiuc.edu:77300035:000:3094
Nf-From: p.cs.uiuc.edu!johnson    Oct 16 07:09:00 1989


ObjectWorks for C++ brings to C++ the programming environment of
Smalltalk.  Actually, it is not quite as fast as that of Smalltalk,
and it doesn't catch all the run-time errors like Smalltalk does,
but it is pretty close.  I predict that C++ programmers will like
it a lot.

Folks, Smalltalk is 10 years old!  ObjectWorks is just catching
up with 10 year old technology.  It is true that there really
aren't any programming environments much nicer than Smalltalk,
but that is really an indictment on the CS community.  One of the
reasons has been that people have spent the last 10 years trying
to mimic Smalltalk instead of trying to go beyond Smalltalk.
People try to extend the Smalltalk programming environment model
to handle programming-in-the-many rather than to think of radically
different ways of programming.

Two of the systems that should be studied carefully are NeXTs Application
Builder and Randy Smith's Alternate Reality Kit.  Both of these systems
fit in very well with the OO emphasis on reusable components.  Both could
make it possible for nonprogrammers to play a big role in customizing
systems.  What I would like to see is a Hypercard-like system where the
user can easily add new kinds of objects at the bottom but could program
at the top-level using a direct manipulation interface.  This would be
hard to do with C++, but is probably possible.

Browsers are very good when your library is small, like with 500 or
fewer classes.  This is plenty large enough for most programmers, since
a Unix kernel, a compiler, an accounting system, etc. are all smaller
than this.  However, I don't think that browsers will work well on
really big systems.  Moreoever, browsers work best when you are examining
a system with which you are familiar.   They are not as good when you
are trying to find a component in a libarary that somebody else created.
We need to have better tools for managing very large systems, especially
large databases of components that we only rarely examine.  My guess is
that techniques developed by the information retrieval people will be
useful here.

A problem that will prove to be important in the future is that of
managing change.  It is already an important problem, but people don't
seem to realize it.  Libraries are not static--they change as we learn
from experience how we should have done them in the first place.  If you
change a library then your customers have to rewrite programs that use
the library.  If you don't change the library then it eventually becomes
obsolete, and your customers complain that newer libraries have much better
features and are much easier to use.  This has already happened to systems
like MacApp (i.e. they finally made a big change) and is an old problem in
Smalltalk.  C++ programmers haven't seen this problem yet because none of
the libraries have been around long enough, but they will!  This problem
is one of my research areas at the moment, and with a little luck we will
have it figured out before the problem becomes really severe.

Ralph Johnson - Univeristy of Illinois at Urbana-Champaign