[squeak-dev] The Trunk: Collections-eem.792.mcz

Levente Uzonyi leves at caesar.elte.hu
Thu May 3 21:28:33 UTC 2018


On Thu, 3 May 2018, Chris Muller wrote:

>> On a serious note, libary methods, like that method, ought to be fast,
>
> Every method in the image is a library method, so what do you mean by

Really? Explain me how Browser >> #defaultBrowserTitle, a method I chose 
randomly, is a library method?

> "like" that method?  Below, you said can't base on the situation(s)
> it's currently used, so are there any methods in the image which
> *shouldn't* be so desperately optimized?  I'm just trying to figure
> out your basis for saying "ought" above, about fast but not
> readability.  Are those not the personal priorities of an expert
> developer?  What about the priorities of the students and users in the
> Dynabook dream?

Others have explained why the readability argument is not very convicing.
About your other argument, I also find it rather weak. If Eliot's code is 
too complex for "users", then how could they cope with the 
complexity of #anySatisfy:?

>
>> because you can't know in what situation they will be used. Saying that it's
>> not even used is therefore not a valid reason.
>
> That's only true for the very lowest-level methods.  Generally, it's
> better to design and code for what's known, and NOT try to code for
> the future / unknown.  IF and when that future comes, it'd be easy
> enough for you to deal with any performance issues at THAT time.  In
> the meantime, we "ought"  :) to keep as much beautiful minimal
> elegance as we can.

So, if I decided to write a mail transfer agent, and I found that 
optimizing #isAsciiString would bump the throughput by, let's say, 10%, 
then and only then would I be allowed to change the implementation in 
Squeak? Or should I keep my optimized version in my image, because it's 
not considered generally useful?

Levente


More information about the Squeak-dev mailing list