Casey Muratori is basically describing Data Oriented Programming. Perhaps the most famous talk about it was from CPPCON 2014 [1]. I come from an embedded background (microcontrollers and bare metal) so I'm pretty sympathetic to his argument. If you work in it long enough, it feels natural and "clean". Uncle bob's Clean Code probably feels natural to Java devs.

Personally, my biggest gripe comes from experiencing people trying to introduce it to a team. Inevitably someone tries to enthusiastically implement some part of it and suddenly are writing 1 line functions everywhere. I think this is the type of thing Casey is also implicitly talking about when he's railing against the rules being brought up.

[1] https://www.youtube.com/watch?v=rX0ItVEVjHc

I like this article. At the start I feared it was going to be one of those polemics written by someone who's never had to read other people's code, or worry about speed, efficiency or third party users.

However thats not the case. The author has distilled lots of experience into something reasonably readable.

The other cool thing about an OOP approach to this problem is that you can hide your optimized LUT behind the OOP if you're careful about the design of it. This lets you have your cake and eat it too. Your users who might be more comfortable with an OOP approach get a way to declare the kinds of shapes they're interested in and the number of shapes they want to work with. Then you can take responsibility for building a LUT that meets their needs and give them the supporting optimizations they need to be successful.

the problem with code is that the abstraction changes and data needs to be migrated:

e.g. a user is enabled if they have paid... time passes... now a user is enabled if the team they belong to has paid. now you need to move the logic to another struct / class and the data to another table.

now this is where "payables" and things come in and you start going the path of clean code with 1000 classes.

instead, the best way to do this is immutable data streams and event listeners.

after over a decade of programming, i feel for most software with a customer focus (not low level, embedded etc), immutable data streams where data flows through and listeners do things to themselves is the best way.

If anyone wants to read the antithesis of Clean Code, check out "A philosophy of software design"

I think a programmer can set badly any good pattern. We have onion pattern in our code and I get sick every time I enter it. All's great but it implements a graph of state changes navigating which resembles debugging a regexp, also all the ctrl+click navigation is broken because there's one general method for each message root type

The most important thing when evaluating things you need to know is: context matters

Principles arent universal across technologies

Hell, principles arent even universal across software kind (e.g goto arent used in C# web dev, but std lib? yes)

So like, Clean Code really does say you should write four line functions, and does not put caveats on that statement, Uncle Bob even gives a lengthy terrible-looking example of a class written with 4-line functions and holds it up as the ideal. His views as expressed in that book are extreme and uncompromising, the “everything in moderation, there are many ways to write clean code” stuff is a rhetorical act he does when people call him out. Then when they’re gone and he thinks he can get away with it he starts speaking in absolute statements again.

Like, this is a conversation Uncle Bob had with Casey Muratori on GitHub, I came away feeling like Uncle Bob is more interested in playing rhetorical judo than anything else: https://github.com/unclebob/cmuratori-discussion/blob/main/c...

tldr;

Premature optimization is the root of all evil. (Donald Knuth)