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@gmx.net