A different way of doing Smalltalk development (was: Tales
of Dying Objects)
Allen Wirfs-Brock
Allen_Wirfs-Brock at Instantiations.com
Wed Jun 21 00:58:42 UTC 2000
At 12:24 AM 6/19/00 -0700, Paul McCullough wrote:
>...
>I suggest we consider moving Squeak to a different style of development --
>one in which we can deliver stand-alone apps of minimal size and, perhaps,
>still support the free-wheeling style which many have grown accustomed to.
>I freely give credit here to Allen Wirfs-Brock who asked some of these
>questions years ago. Hopefully, Allen will add to this discussion.
...
Paul, thanks for the plug. Those who are unfamiliar with our work might
what to take a look at:
http://www.smalltalksystems.com/publications/_awss97/SSDCL1.HTM
and
http://www.smalltalksystems.com/publications/_awss97/INDEX.HTM
[warning, about to enter semi-incoherent sermon mode]
While it is indeed possible with the appropriate tools to create small
footprint programs written using the Smalltalk language (or even Java) I'm
not at all certain that such tools actually solve "the problem". In fact,
I'm beginning to suspect that current object-oriented languages,
"methodologies", and tools naturally lead to bloated, excessively
coupled, fragile "designs". (Of course, I may just be overly grumpy from
too much Java exposure but actually I think not).
Here's an example from the Java world but don't snicker, very similar
things occur with Smalltalk. I happen to have a whole-program optimizing
compiler for Java that will report interesting statistics about the program
it is compiling. So I compiled the simplest possible "hello world" program
at the highest level of optimization using two different generations of
core class libraries. Here's some of what my compiler told me:
JDK 1.1.8 classes JDK
1.2.2 classes
Statically reachable types 179 296
defining n methods 2445 3719
Emitted Runtime types 155 270
Runtime instantiable classes 91 147
Emitted callable methods 376 681
X86 code segment size (bytes) 96,683 199,918
("types" are either classes or interfaces, emitted callable methods does
not include methods where all call sites have been inlined. Your mileage
may vary)
The JDK 1.2.2 class library is clearly a much more functional, more
versatile, more reusable, more extensible library than the JDK 1.1.8
library. Of course, my little program doesn't require or directly use any
of the new functionality. Now, I'm sure the designers of the 1.2.2
enhancements didn't set out to make things bigger but they probably did
want to make things "better" so they added new features, generalized
algorithms, replaced classes with framework, and generally tried to produce
cleaner, more object-oriented code. However, from the perspective of my
hello world program they just ended up with increased coupling and bloat
that even my very aggressive compiler can't get rid of.
I think much of the source of this problem is that object-oriented language
like Java and Smalltalk are just facades on the classic Von Neuman address
space and are built upon a foundation of direct, uniform intra-address
space references. These pointer references are one of the tightest possible
forms of coupling. Such languages make too easy to build tightly coupled
monolithic programs that operate within a single address space. In doing so
they discourage the creation of distributed, loosely coupled, adaptable
systems. This must feel like a dead end if you believe we are moving
towards a computational ecology based upon massive numbers of pervasive,
communicating computing devices.
I love Smalltalk but I've seen far too many Smalltalk programs grow in
complexity and fragility until they collapse under their own weight.
Smalltalk is a joy to program but it can also be a rut that limits our
achievements. What should be done instead? If I was directing a research
budget in this area I would start by saying we have abandon the Von Neuman
address space. Initially I'd still use a "conventional" languages like
Smalltalk or Java but I'd set a complexity limit on what I would allow in a
single address space (500 classes??). Anything that could not be
accomplished within that limit would have to use multiple collaborating
programs (shared address spaces not allowed). Hopefully, this would force
the development of the languages, tools, and techniques really needed for a
pervasive computing ecology.
Thanks for the pulpit,
Allen_Wirfs-Brock at instantiations.com
More information about the Squeak-dev
mailing list
|