>If the problem is to write a trivial text filter, or a "hello, world" 
>filter, write it in Perl, C or the scripting language du jour.  If 
>the problem, however, is the back-end of a highly data-intensive 
>enterprise system, write it in some combination of a fine database 
>system, a fine high-end development system (with lotsa' tools and 
>built-in libraries) and be thrilled that your greatest costs  -- cost 
>of human being developers and maintainers -- is minimized thereby, 
>and the chances of failure due to greater clarity are likewise 
>simplified.
>...
>However, I was amazed again how short the window was before memory 
>and costs of hardware didn't matter any more (less than a decade).
>
>Squeak **IS** clearly bloated, but not that awfully bloated.  A few 
>megabytes of overhead for the clarity of a solid UI library and a 
>solid development system is well worth the cost in most applications.

I think the issue of resource consumption depends a LOT on your assumptions
about the environment. I'd also like to suggest environments labeled "the
back-end of a highly data-intensive enterprise system" may be very resource
limited, on a per user basis.

The reason I say this is, an appropriate architecture for large back-end
systems may NOT be a large monolithic program, but a group of "chunks" that
can have transactional recovery, and controlled security, and robust
on-line evolution. Consider the differences between a giant back-end
program, processing many concurrent requests vs. tiny little chunks hooked
together by some system framework (let's call it a transaction control
subsystem). If there's a fault (hardware or software) in the large program,
you may loose the state of 5000 users. If you have a fault in a tiny chunk,
you may loose part of the state for 1 user, and potentially can even
automatically restart the chunk, causing only a delay. An increasing number
of people need to write systems that are designed in the "small chunk"
style. The issue is it's highly inefficient to write these chunks using the
current Squeak implementation, as it was never designed for this kind of
environment. If you have 5000 concurrent chunks executing, it's really not
ok for each one to have multiple megabytes of sparsely touched working set.
It would be very efficient if you could have small isolated chunks, which
accessed a common pool of objects (read-only). You might also get away with
a session Smalltalk process (that maintained session data, and managed
connections), and a number of worker processes, that had requests
serialized. This is exactly what Apache does. Worker processes also
periodically die out, to reduce the failures caused by corrupted memory or
leaks. The failure of a worker process interrupts a single user's
transaction. Session data persistence is not so well controlled.

I think Smalltalk as a language might be good choice for creating these
small chunk systems. What's missing is the ability to efficiently activate
each chunk, and run it in a "controlled" environment. I think the concept
of persistence of state is also an issue, which again could be resolved
with an appropriate implementation. 

I'd also like to suggest, this view of things may not be all that different
from what might be appropriate for the computer workstation sitting in
front of me. 

Systems moving toward a single generic "view/controller" (of html code) and
developers putting all their effort into the "model" (the server that spits
out data to the generic view), seems to be a trend, for better or worse.

- Jan