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