iteration - don't optimize it

Richard A. O'Keefe ok at atlas.otago.ac.nz
Fri Feb 1 01:06:45 UTC 2002


"Mark Mullin" <mark at vibrant3d.com> wrote:
	For the record, C++ iteration is what we use to deal with
	problems that really vex the computer but that the user could
	care less about.  Smalltalk has a richer and more powerful set
	of iterators and collections than STL, but the costs of such a
	dynamic flexible solution are more than we can bear.

I really want to stress that it is not the architecture of Smalltalk
container classes or iteration that is "more than [someone] can bear".
The issues are
 - fixed program -vs- dynamically loading program
 - native code generation -vs- JIT -vs- byte codes
 - type system
 - "expanded" objects or not
 - inline code expansion
 - special treatment of "primitive" types -vs- everything's an object
 ...

Take Eiffel, compiled using SmallEiffel
 - compiles whole program in one go so has excellent knowledge of what
   is used, what is polymorphic, what isn't (which is most things, even
   though Eiffel has no monomorphic constructs as such)
 - generates native code (via C)
 - static type system with *simple* templates (unlike C++, Eiffel type-
   checking isn't a Turing-complete problem)
 - expanded classes and individual expanded objects are available
 - inlines like crazy
 - BUT is pure OO: everything's an object, even 77.

That compilation technology would allow collection classes, streams, and
iterations with recognisably the Smalltalk architecture to work at C++
speeds or better.

The "assertion" technology (inherited class invariants, method preconditions,
and method postconditions; loop variants and invariants; specific checks)
helps to pinpoint errors quicker than you could with a debugger.

What Eiffel sacrifices is the DYNAMIC character of Smalltalk,
and of course its IDE.  (I haven't tried ISE's system and don't know how
well "Melting Ice" works in practice.)

The beauty and power of Squeak is amazing; its fragility is scary.
By this I mean the way things stop working between one release and the next,
the number of projects out there that just don't load any more.
On the one hand that kind of thing practically doesn't happen in Eiffel;
on the other hand such projects could never have been written in Eiffel
in the first place.

But let's NOT blame the collections/streams ARCHITECTURE for anything, OK?



More information about the Squeak-dev mailing list