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.
> I came away feeling like Uncle Bob is more interested in playing rhetorical judo than anything else
That's his only option.
I am not trying to speak ill of the man, but I am quite dubious of his advice.
I truly believe everyone has something to offer. However, I would feel more inclined to follow Uncle Bob's advice if he actually had the portfolio to back it up.
If Linus Torvalds were to give advice on how to build an operating system's kernel, I feel as though I should listen. Not only because Torvalds had/has good ideas, but because he also has demonstrable experience and work to back up his claims.
Uncle Bob has a lot of words, but projects speak louder.
Perhaps the Uncle Bob principles do not create the best code, or most clear code, but more dogmatic adherence does make it harder to create the code I see on a daily basis that is so much worse and much more unmaintainable.
Isn’t that the same case for Robert Martin? I’m not going to be the one defending Uncle Bob, but most of the people out there giving advice about “clean code/architecture” come from the consulting world without any work that can be analysed.
I am rather ignorant of the world of consulting. If someone like Uncle Bob consults a company and the company implement his ideas with his guidance, then is a consultant like Uncle Bob typical gone by the time maintenance rolls around?
I ask because I can see his ideas being great to him if he is never around for damage control because what feedback does he truly have that cannot be fought back with some 'Get out jail free' card like "The company deviated from my plan after I left!"
Yeah, I get the impression that he just sells his image as some "guru" of software engineering, and that he doesn't actually deal with or write much real life code.
I think the aspirations of the agile manifesto are great, but basically everyone involved in it was an enterprise software methodology consultant. I forget who the exception was; someone will remind me.
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.
My work has adopted DOD for roughly the last 3 years. Compared to OOP/FP[0], I would say DOD is generally more performant, more work to set up initially, harder to adapt to small changes, and easier to adapt to big changes.
DOD is generally going to have less in the way of user-defined classes/types. This can sometimes make it harder to convey the intent of the code, but in term it means there's a lot less to do if there's a big change in the problem domain – e.g. you don't have to refactor a whole class hierarchy.
Jonathan Blow has mentioned some ideas in his language Jai that would let you write code that can easily switch between OOP and DOD ideas, e.g. Array of Structs vs. Struct of Arrays, and I've seen that in some languages like Julia as well. I'm hoping it becomes more common place so that there's less of a tradeoff to make.
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.
I fully agree, but this requires a certain level of experience to organize code in a way that makes it easy to navigate and modify. It's quite easy to end up with with "rube goldberg" code where you don't know what listeners are being triggered by what streams. Or to end up with a ton of edge cases where things aren't handled properly when issues occur.
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...
That's his only option.
I am not trying to speak ill of the man, but I am quite dubious of his advice.
I truly believe everyone has something to offer. However, I would feel more inclined to follow Uncle Bob's advice if he actually had the portfolio to back it up.
If Linus Torvalds were to give advice on how to build an operating system's kernel, I feel as though I should listen. Not only because Torvalds had/has good ideas, but because he also has demonstrable experience and work to back up his claims.
Uncle Bob has a lot of words, but projects speak louder.
I ask because I can see his ideas being great to him if he is never around for damage control because what feedback does he truly have that cannot be fought back with some 'Get out jail free' card like "The company deviated from my plan after I left!"
Like "small functions." I say, okay, okay, stop writing these 2000 lines of spaghetti, I'm a hundred percent on board.
Then when you get to the concrete example, it's decomposing this 15 line function.
Good idea. Calibration is waaaay off.
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
DOD is generally going to have less in the way of user-defined classes/types. This can sometimes make it harder to convey the intent of the code, but in term it means there's a lot less to do if there's a big change in the problem domain – e.g. you don't have to refactor a whole class hierarchy.
Jonathan Blow has mentioned some ideas in his language Jai that would let you write code that can easily switch between OOP and DOD ideas, e.g. Array of Structs vs. Struct of Arrays, and I've seen that in some languages like Julia as well. I'm hoping it becomes more common place so that there's less of a tradeoff to make.
No.
However thats not the case. The author has distilled lots of experience into something reasonably readable.
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)
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.