On 3/1/2023 9:39 AM, JC van Winkel via SG20 wrote:
> I came across this article
> <https://www.computerenhance.com/p/clean-code-horrible-performance>
> (summary of a video <https://www.youtube.com/watch?v=tD5NrevFtbU>)
> that says that we are teaching people the wrong things.
>
> My feeling is that the presenter is cherry picking the worst possible
> examples and values micro-optimizations over maintainability and I
> wonder how often the presenter has worked on really large code bases...

I only watched to the middle where it went overboard... till ten it was
okay-ish with some tweaks. What generally makes me shut down lectures
is wild references to a school (clean code here) with no real telling
what they state. AKA straw-man.

IME "pushing hierarchies" was a thing for a few years in the 90s and
mostly stayed there. Really with lot of crap and one-sided, just
sweeping alternatives off the table. And discussion threads very low
quality. And if we had examples at all, they didn't compare equivalent
functionality even for essential use cases, never mind realistic ones.

My list of "clean code" only has DRY and KISS. And if I'd discuss the
shapes example, the latter would kick in. IF you have a closed set of
4 shapes and an interface of 1 function, then indeed making them into a
"hierarchy" is a likely KISS violation. And I would probably just write
a single class similar to one presented.

But if we're only in design brainstorming, the question is about that
big if. How many shapes we will have over time. How many additional
functions in the interface. Let's take the example and see code delta
if we add an extra function or an extra type.

As on performance. what I found strange was the guy's measurement. He
only found 1.5x penalty in this toy example. If we add real work, this
diff will disappear to noise level. In some other thread one recently
mentioned how much effort was put into compilers to reduce virtual call
penalty to minimum. It seem they succeeded. ;)

IMO this vid can be used for good teaching purposes pointing out what
was not presented. While admitting that abstraction DOES have its costs
and in general we're in the business of managing tradeoffs.












>
> JC
>