From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: comparing object-oriented platforms
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sat, 3 Oct 1992 14:00:04 GMT

peterg@netcom.com (Peter Goodall) writes:

>Most of the performance and size problems I've seen are design problems.
>The most common design problem is lack of a design, the second most common
>is working against Smalltalk rather than with it. For example 
  example deleted

>I have seen people slow systems by 50%+ by doing this stuff.  In just one
>place!

>That problem is more of technique than design. The real killer is, as I
>cheekily said at Momenta, 'Unfortunately, due to the robustness of the
>develoment environment, the system kept running.' 

>Smalltalk is so robust that systems are often dead, but they won't lie
>down. 'Design' by attaching special case behavior makes big ugly slow
>incomprehensible systems. If you start adding special cae code to the
>system. Stop, and think what was wrong with the system mode that a special
>case was needed. Tear the system down and rebuild it to be consistent.
>Often.

This reminds me of something I have been meaning to post for awhile.
It is about the difference in program management philosophy between
Smalltalk and some of the other object-oriented communities.  I'm
not sure why this difference exists, because the philosophy is language
independent, and I've even known some C++ groups to follow it.
It is related to Fred Brooks admonition to "Plan to throw the first
one away, because you will anyway".  Nevertheless, it seems to be a
hall-mark of the Smalltalk community, and is something that people new
to Smalltalk need to learn.

Peter's advice to tear your system down and rebuild it often is one
that you often hear on the lips of Smalltalk grey-beards.  (I don't
know Peter, so this is not a comment about his age!)  It seems very
idealistic.  Who has time to rewrite a system over and over again?
We have deadlines to meet, customers to satisfy.  It is more important
to add new functions than to go back and reimplement old functions.

However, this idealistic advice is intensely practical.  Often the
fastest way to write new code is to rewrite the old code first.  It
is often hard to add a new feature because of the way the system is
organized.  Instead of just hacking up the old system, reorganize it! 
If you understand a system well then you can often change it by just
modifying a small piece of it, so if a system is hard to understand,
simplify it and you will probably be able to make the change easier.
Making software reusable requires parameterizing those things that
need to be changed, so if you need to change something that is not
parameterized, reorganize your software and it will not only make this
change easier, but the software will become easier to reuse in the
future. 

In the long run, refusal to rewrite old code leads to very large systems
that nobody understands and that are nearly impossible to change.  
Of course, we shouldn't rewrite code just for the sake of rewriting
it, but because we see things that are wrong and need correcting.
Further, if you looked carefully at what Peter calls "tearing down and
building again" you would probably notice that the new systems looks a
lot like the old and shares a lot of the same code.  For example,
though MVC 4.0 is entirely different from MVC 2.5, I found that most
of my lecture notes on 2.5 were still accurate.  The details had
changed, but not the big picture.  

The Smalltalk community seems to understand this much better than any
other.  People who are not in it shudder when they hear that ParcPlace
comes out with a new version every year that requires us to change
our software.  But we are constantly rewriting our software, so we
EXPECT ParcPlace to do the same with theirs.  If they don't, they are
not improving their software.

One of the things I have noticed is that many of the changes to
improve software are stylezed.  For example, three-quarters of the
changs from 4.0 to 4.1 were either changes to the names of methods
or moving a method to a new class (usually out of SystemDictionary).
I've been thinking about this refactoring of programs for some time,
with the result being that Bill Opdyke decided to study it for his PhD
work.  He finished recently, and his thesis is available on
st.cs.uiuc.edu in /pub/papers/opdyke-thesis.ps.  Bill's work was
primarily theoretical, and was in the context of C++, though we
decided that C++ was such a big language that it was hard to make
tools to manipulate it.  Dan Walkowski is currently building a
Smalltalk "refactory", and will be using many of Bill's algorithms.
It will be interesting to see how Smalltalk changes our choices of
algorithms for refactorings, or whether it changes the refactorings
that we think are important.

I expect that a refactory will make it much easier to refactor
programs.  It will automate simple refactorings, and will let us
compose complex ones from simple ones.  Unlike when we do it by hand,
the refactory will ensure that the new system has the same behavior as
the old, so refactoring a program won't introduce bugs.

I'm hoping to release a first version of the refactory before
Christmas.  When it is released, it will be announced here.

Xref: sparky comp.lang.smalltalk:1968 comp.lang.eiffel:1194 comp.object:3776