Squeak for the masses? [was: primitiveApplyToFromTo]
stephane.ducasse at gmail.com
Mon Sep 18 09:48:01 UTC 2006
But I understand what Bryce concerns.
Now if we would start to really benchmark central part of squeak I'm
sure that we would get some surprises.
On 18 sept. 06, at 11:17, Klaus D. Witzel 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
> Also, look into complex applications which can neither be created
> nor be maintained by a single person, or understood by a single
> Why shouldn't Squeak become a #1 choice in such situations.
> I doubt that application developers want to understand the
> internals of a VM or the internals of a library (Collections in our
> case here, libc as an example in other cases), perhaps their boss
> (the $$$ decision maker) also doesn't want that. I doubt because of
> long time experience.
> Let's bring Squeak to the masses. Or, am I wrong with this? I run a
> commercial business and want to base my success on Squeak. Anyone
> out there telling me that I should not invest into Squeak, please
> let me know, in squeak-dev or off-list. Thank you.
> Please don't misunderstand: I'm not asking that
> primitiveApplyToFromTo must be in each and every VM. Neither do I
> have something against the preferences of developers. But I want
> freedom for making decisions.
>> On 17 sept. 06, at 22:04, Bryce Kampjes wrote:
>>> Personally, I'd prefer a library that I can easily understand
>>> that is
>>> fast enough for 99% of it's uses. That for 1% of cases, I need to
>>> a custom solution is an acceptable trade off for understandability.
More information about the Squeak-dev