Allen writes:

>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

I am highly sympathetic to this argument, but I will observe this: 
the best language, measured by space heuristics, for writing a hello, 
world program is clearly going to be "C" or one of the more 
traditional, "bare on bones" programming languages with minimal tools.

So, what?

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.

In other words, use the right tool for the right job.

My first business was built on a program I wrote for a 32K (then a 
Cadillac!) Apple ][, Wizardry.  I was amazed after the memory-bloat 
of mainframe programming that we were again counting bytes, indeed 
bits, loading interpreters-on-interpreters to preserve space against 
time, and so forth, just to make a big game fit on a little machine. 
It was like going back to my first job of writing microcode on a 
little minicomputer.

**AND I LOVED THOSE DAYS**

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.

Sure, if we are coding for palm-pilots, go back to the old ways.  But 
for many real projects, particularly those that I have been working 
on lately, minimialism would be the kiss of death.  Indeed, it was -- 
many subsystems written on the metal in C are virtually useless and 
unmaintainable, but were trivially rewritten in bloatware in a matter 
of weeks.

So again, I sympathize with Allen's remarks, but I am not sure the 
tradeoff is worth making.  If the cost of minimalism is too great, 
perhaps we shouldn't pay the price.

I do not oppose the project, and am very interested in Allen's work. 
It would be a mistake to see my posting as gainsaying.  The real 
answer is a close balancing of concerns in view of particular 
projects and particular needs.  What I want to do with this message 
is simply to put the "other side of the story" on the table.
-- 
Andrew C. Greenberg		acg at netwolves.com
V.P. Eng., R&D, 		813.885.2779 (office)
Netwolves Corporation		813.885.2380 (facsimile)
www.netwolves.com

Please use werdna at mucow.com instead of werdna at gate.net