At 3:43 AM 6/18/99, Peter William Lount wrote:
>Obviously I have a different style then some of you. This is fine. Your
>style is fine. There is not any one right style.  I would hope that all his
>methods are not this large and I would recommend that he see if he can
>refactor the method in some way to shorten it but ultimately it's his call
>and not mine. It's a judgement call for him to make and Smalltalk should
>not enforce some arbirtary limit to satisfy the "temporary variable
>police".

I am writing a reply to this paragraph because it is so important.
It is also wrong in a very important sense.

It is common in our culture to say that everything is relative, that
there is not one right way of doing things.  We make fun of people who
set standards.  So, it is natural to sympathize with Peter.

However, for code to be readable, it has to follow conventions.
The C++ world shows what happens when every development group
has its own set of standards.  Chaos reigns.  Conventions are
partly arbitrary.  There is not really a good reason why one
should drive on the right or left side of the road; either direction
works as long as everybody follows it.  Other conventions have good
reasons.  Long methods are hard to read in a browser, for example.

One of the big advantages of Smalltalk is that the original
Xerox PARC SMalltalk-80 had a very consistent style.  Because the
people who developed other Smalltalks usually had used Smalltalk-80,
they learned its style and propagated it.  None of the other
versions of Smalltalk are as consistent as it, but Smalltalks in
general have a more consistent style than other languages.  This
makes Smalltalk code easier to read than it otherwise would be.
Part of learning Smalltalk is learning how to write code that fits
into the image.  So, as long as there are new Smalltalkers, there
will be discussions about how to rewrite methods to make them
shorter, how to name methods, how to handle control flow, and
other low-level coding questions.  It is very dangerous to say
that it is just a matter of style and you can make up your own
mind.  If you are beginner, you need to learn the standard style
so you can read other people's code and so you can write code
that fits in.  If you are an expert then it is OK to break the
rules, but if you don't know what the rules are then you are not
an expert!

Peter is an expert, so he can break the rules.  But I will not
let him get away with saying that rules are not important!

Peter is also wrong about the reason the VM limits the number
of variables.  All VMs limit the number, the question is what
the limit should be.  It is easier to implement VMs with smaller
numbers.  The VM designers looked at real code, decided it didn't
require large numbers, so made a decision that allowed them to
make programs smaller and faster.  I have been programming in
Smalltalk for 15 years, and have never written a method that
the compiler wouldn't accept because it had too many temporaries.
However, I once wrote a program that generated code that the
compiler wouldn't accept!  That was how I found out there were
limits.  Yes, VisualWorks (which is what I use the most) has
big limits, but it used to have the same limits as Squeak.
I used Tektronix Smalltalk for a long time, which had the
same limits, too.

So, the limit is small because Smalltalk programmers don't
use lots of variables.  It is not small to prevent people
from using lots of variables.

-Ralph Johnson