Smalltalk › Squeak › Squeak - Dev

The Inbox: Graphics-nice.446.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

marcel.taeumel

Re: The Inbox: Graphics-nice.446.mcz

Hi Stef.

> Real pedagogical value comes from explaining complex topics clearly, not from simplifying them.

Slightly disagree in this context. If you sacrifice readable abstraction (or modularity or information hiding in that sense) for performance, code comments can only try to alleviate the actual issue. First and foremost, source code should be written for humans, not machines, to understand. Otherwise systems with a lot of inherent complexity would be very challenging -- if not impossible -- to build and maintain.

We should be very careful with every low-level detail we burden the high-level programmer with. I find the phrase "[...] problems that users will have to learn sooner or later [...]" very problematic in the sense that it seems to "just give up" on readable, high-level abstractions altogether. Of course, one should not be too naive about this.

Still, we can do better that comments. And we still need more bytecodes/sec and sends/sec. :-D

Best,

Marcel

Am 22.02.2021 16:36:31 schrieb Stéphane Rollandin <[hidden email]>:
> Eliminating all the intermediate objects gives much less expressive
> code as Tom underlined
> But providing only naive implementations hides the performance
> problems that users will have to learn sooner or later...

Exactly.

And code expressivity is a dubious criterion IMO: especially in
Smalltalk, the readability of a specific algorithm can be improved by
refactoring/renaming its primitive methods, or more simply by commenting
the non-obvious parts.

Real pedagogical value comes from explaining complex topics clearly, not
from simplifying them.

Stef

Stéphane Rollandin

Re: The Inbox: Graphics-nice.446.mcz

> We should be very careful with every low-level detail we burden the
> high-level programmer with. I find the phrase "[...] problems that users
> will have to learn sooner or later [...]" very problematic in the sense
> that it seems to "just give up" on readable, high-level abstractions
> altogether. Of course, one should not be too naive about this.

Maybe we do not have the same idea about what "readable" means, because
I do agree with you that the code must be readable in all cases. But, to
me, readability cannot come from hiding complexities away - it means
finding a proper vocabulary to explain them clearly, as they are and, as
Nicolas said, as they will bite anyway.

Stef

Chris Muller-4

Re: The Inbox: Graphics-nice.446.mcz

In reply to this post by Levente Uzonyi

> > The most optimized version with the inlined temporaries is a great implementation but looks like quite a beast to me, which in my opinion would be sad for something that appears in our standard library. After looking for
> > senders of Rectangle class>>merging: in my trunk image I only saw one critical path in recordInvalidRect:, which appears to on average trigger merging: only once per damaged frame. Is there another use case we know of?
>
> My stance on library methods is that they need to be optimized because you
> don't know how people will use them. If they are fast, people will be
> happy. If they are not, you'll leave a bad impression.
>
> This discussion exists, because Karl changed the method last year and
> noticed that the performance got worse[1]. And, while he was convinced
> about arguments always being sequenceable, it turned out that they may be
> sets as well.

It's a creation method. Creation, initialization, and error-handling
are all areas that don't typically need to be optimized for execution
performance. Afterall, how many Rectangles will you need / be able to
create before you start to run into other performance and memory
issues? In seemingly trying to optimize for a gaming use-case, this
plays against your statement that we don't know how people will use
them. Optimizing for speed by only a small percentage (vs. Tom's
#reduce: solution), but at the cost of restricting the input type, DID
leave a bad impression on someone. Now they have to send "asArray",
probably negating that tiny #allButFirstDo: performance gain.

- Chris

marcel.taeumel

Re: The Inbox: Graphics-nice.446.mcz

In reply to this post by Stéphane Rollandin

Hi Stef.

> But, to me, readability cannot come from hiding complexities away - it means
> finding a proper vocabulary to explain them clearly, as they are and, as
> Nicolas said, as they will bite anyway.

Sure. "Leaky abstractions" (https://en.wikipedia.org/wiki/Leaky_abstraction) can be challenging. I just disagreed with the way you "sugarcoated" the effect of comments. Yes, you would have to explain the essential complexity for a hardly readable piece of code with a natural-language comment. Yet, it should be still considered a code smell, given that one did not yet managed to express the solution in idiomatic Smalltalk. :-) And maybe the programming language will never be able to express that essential complexity nicely because it may just not be a good fit for the problem at hand.

Best,

Marcel

Am 22.02.2021 17:42:03 schrieb Stéphane Rollandin <[hidden email]>:
> We should be very careful with every low-level detail we burden the
> high-level programmer with. I find the phrase "[...] problems that users
> will have to learn sooner or later [...]" very problematic in the sense
> that it seems to "just give up" on readable, high-level abstractions
> altogether. Of course, one should not be too naive about this.

Maybe we do not have the same idea about what "readable" means, because
I do agree with you that the code must be readable in all cases. But, to
me, readability cannot come from hiding complexities away - it means
finding a proper vocabulary to explain them clearly, as they are and, as
Nicolas said, as they will bite anyway.

Stef