Herbert

I can tell you that we are ****really**** concerned by speed and by  
making sure
that people can commercially use Squeak!
Really!!!!!
This is why all the speed up changes in Morphic for 3.9 done
by eddie and others (if they do not break anything) will be included  
once tested (by others :)).

So we do not want to trade beauty for speed. But we need to clean Squeak
and make sure that changes can happen.

Stef



On 31 août 05, at 20:41, Herbert König wrote:


> Hello David,
>
> DPH> Why do you say this?  There are ways and means to deal with  
> this - if it
> DPH> is actually a significant problem.  Time saved in
> DPH> development/maintenance may mitigate this, also.
>
> Software being said to be sluggish is in a big distvantage. In road
> design where I plan to use squeak commercially there is a speed
> difference between 3.6 and 3.7 and not using accessors and pushing
> methods down the hierarchy makes a difference.
>
> And though I like LookEnhancements I always notice the speed penalty.
>
> I have big hopes for Exupery and Morphic cleanup/splitters, which seem
> to address the main speed handicaps.
>
> As for traits, there are times when I feel I have to overburden some
> classes due to single inheritance and there definitely is code which
> isn't speed sensitive. So I appreciate this too and as people point
> out that you can use it but needn't to I think it's an improvement.
>
> As always judicious choice is the key and the more tools you have at
> hand the better you are off.
>
> DPH> Possibly -- but I do not think Squeak was really ever meant to  
> be a
> DPH> production environment -- would be nice to be able to throw a
> DPH> (preferences) switch to  'production' :-)
>
> At least seaside seems to aim at production and there seems to be a
> direction making Squeak usable for production. In the long run I think
> these attempts will give Squeak a better future.
>
>
> Cheers,
>
> Herbert                            mailto:herbertkoenig at gmx.net
>
>
>
>