Love this "Scis" example from Naming Things Is Easy by Nic Barker

Media
1

(This is not Zig specific but close to the philosophy of simplicity that is characteristic for schools like Systems programming, Data Oriented Design and overall, in Zig community.)

I was just re-watching old Nic Barker’s video with tongue-in-cheek title “Naming Things Is Easy” in which he talks about the cost of abstractions and the effect they have on the code. (And some thoughts on how to mitigate these problems.)

The video is great but this slide just pops out to me because it gives such a beautiful example:

When you split the pair of scissors, you now not only have the complexity of having to compose stwo sub objects, but even worse - you have to come up with a name for half a pair of scissors.

Congratulations, you and your team can now argue about whether it should be called Scis or HalfScissor or BladeWithHoopHandle.

(It’s closely related to a part that starts around 11:00)

Just in case you don’t know Nic Barker’s channel: to me his channel is one of the best I know about programming and while every video is excellent, to me—as someone who has been excited about OOP principles for most of my career (only to fail miserably when applying those principles to a working piece of software that matters, as one does)—especially his “Intro to Data Oriented Design for Games” has (along with Andrew’s “A Practical Guide to Applying Data Oriented Design” talk) been essential in changing the mindset back to “normal”.

2

Bad straw-man example. It’s clearly a ScissorsBlade.

3

ok, maybe the example could be better, i’ll give you that.

What i really love is how the argument shows that the abstraction directly creates the cost. And i do think the “scissors” example is good in that it’s something that we’re not used to referring to in components. Of course, in practice you could have a valid reason to treat each blade as separate entity, and in such case it might not be too hard to come up with a name.

I also feel like it hints at this “lure” towards abstractions without justification. (I still feel it sometimes but it used to be worse when I was in OOP mindset.) There’s something attractive about “scissors are just 2 blades” abstraction which might be even seductive if you’re an OOP programmer trained on examples like “table has 4 legs, chair has 4 legs”. Now I know following that this is almost always just wrong: no matter components, I always want to use scissors as a whole.

If I find myself pulled towards abstractions like that, it usually means that I don’t understand what i’m doing and I’m just shuffling things around, perhaps too tired to actually bring myself to think about the problem at hand.