>I don't know how Squeak applications will be distributed in the future. If
>we take the current approach of 'closed' programs, then we are in the right
>direction. If we think that distributed applications could be opened and
>extended, then we will have to live with late-binding and think of some
>other way to gain efficiency (Type Feedback perhaphs...).

I have found Squeak stunningly fast for most tasks I have set out for 
it.  I am often surprised at what it is capable of doing, and how 
well it performs, particularly given its byte-coded interpretive 
nature.  When I need truly blistering speed, I simply refactor so to 
identify the tightest inner loops, and recode them as plugins, which 
technique seems to always gets me the order of magnitude required.

As to the system proper, Squeak is incrementally moving to greater 
improvements all the time.  David mentioned that LargeIntegers were 
slow.  Stephen Rudlof and Dan both reimplemented, each party's 
solutions generating orders of magnitude of improvement.  That seems 
to be the way things get sped up, but when and where they are really 
needed.

On the other hand, Squeak, precisely because of its flexibility and 
reusability, in no small part BECAUSE OF LATE BINDING, has become an 
enormously powerful, elegant and highly functional tool.  Because of 
a cultural desire not to limit Squeak, and to eschew machine 
dependencies where possible, Squeak runs pixel-for-pixel identically 
across platforms, delivering a capability promised, but undelivered 
by many current technologies, including the beloved, peculiarly 
static-bound when necessary Java.  (I wrote a birthday present --a 
multimedia game-- for my wife on my office PC, delivering it without 
modification to her iMac just by sending an e-mail attachment).

Finally, while static-binding will certainly lead to some 
improvements, do we really know HOW MUCH more improvement is 
possible?  Squeak already does method caching, which provides a form 
of type inferencing, that may well provide the 95% solution. 
(Indeed, in the liited cases where the cache fails frequently -- the 
highly polymorphic method calls -- how much better can a static 
compiler do?)  Is it possible that bying into the limitations of 
static binding might not improve things all that much at the end of 
the day?  Has anyone profiled for these improvements or looked at 
these questions?  Would native compilation without these 
static-binding limitations, along the lines of Ian's Jitter, for 
example, provide vastly greater improvement?

Accordingly, I raise the question: why do we think we need more 
"eficiency?"  and of the efficiency we can buy, how much improvement 
will we derive at the end of the day?