Squeak for the masses? [was: primitiveApplyToFromTo]

Klaus D. Witzel klaus.witzel at cobss.com
Mon Sep 18 11:11:26 UTC 2006


Hi Ralph,

thank your your comments!

On Mon, 18 Sep 2006 12:42:39 +0200, you wrote:
> On 9/18/06, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
>> Hi Stef,
>>
>> on Mon, 18 Sep 2006 09:11:16 +0200, you wrote:
>> > me too :)
>> > I always have in mind the nice sentence of dan about the fact that
>> > someone alone could understand smalltalk
>>
>> Look into data centres where the big servers run applications or look  
>> into
>> offices where thousands of workstations run applications.
>>
>> If you can save them a significant portion of CPU time then you save  
>> them
>> $$$ investment, and perhaps win a contract against your competitor.
>
> Scientific applications can be CPU bound, but most business
> applications are not.  Usually they are limited by the network or the
> database.  In a typical office with thousands of workstations, most of
> them never are CPU bound, and the processors on average is 90% idle.

It makes a difference if your graphics / windows / etc open / get drawn /  
save / etc, at 50% or at 100%. Response time (perceived interruption of  
the user's workflow) is more critical for the average user than anything  
else (during an acceptance test: response time v.s. utility, what will  
make it).

I should have mentioned such earlier. But for the rest of it (incl. the  
below): O.K. that is what I hope for :)

Thanks again.

/Klaus

>> Also, look into complex applications which can neither be created nor be
>> maintained by a single person, or understood by a single person.
>>
>> Why shouldn't Squeak become a #1 choice in such situations.
>
> Smalltalk in general, and Squeak in particular, is no better at very
> large applications than other languages.  Its lack of modularity can
> make it worse.  Where it shines is when it allows a system that would
> otherwise need 50 people to be built with a small number.
>
> There have been a number of Smalltalk projects with dozens, sometimes
> hundreds, of people on them.  None have been successful.  On large
> projects, politics and management issues overwhelm technical decisions
> and the value of Smalltalk gets lost.  If you can keep the group of
> developers small then the technical advantages of Smalltalk can
> dominate.
>
> -Ralph Johnson
>
>





More information about the Squeak-dev mailing list