6 ms·

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 backgr

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 https://www.youtube.com/watch?v=rX0ItVEVjHc

jpardy 2y ago
In addition to Mike Acton's talk, there is also the "DOD Book": https://www.dataorienteddesign.com/dodbook/ https://www.dataorienteddesign.com/dodbook/
wiseowise 2y ago
> Uncle bob's Clean Code probably feels natural to Java devs. No.
tcfhgj 2y ago
Don't see a problem with one line functions per se, especially if the name of the function helps understanding the code
- arp242 2y ago
  There no problem with them, and they can often be useful. But there is a problem if all the code is only functions of one or two lines, or when people move things to functions when it just doesn't make much sense, "because it's Best Practice™".
  - pbw 2y ago
    Pylint warns if you have “more than X” for a lot things like local variables, number of arguments, number of member variables, etc. For most of these the limits are in the 5 - 9 range but for lines in a function/method the limit is 50 lines. I agree with this. One line functions are okay sometimes but 50 line functions can be fine as well if clear and well written. A lot depends on the cyclomatic complexity: how many loops and branches, how drastically the indentation varies basically. So I disagree with how strenuously Uncle Bob harps on short methods, although paradoxically I do agree many methods in the wild are too long. Most of them grew to be too long because it’s easier to add a few lines to an existing method than to refactor things —- particularly if a code review is required.
    - LorenPechtel 2y ago
      Yup. I would like to keep things on the screen if feasible, but it's really always cyclomatic complexity that matters. A linear flow of lines, I don't care about until I can't see it all at once but you're rarely writing a linear flow of lines.
      - pbw 2y ago
        I always felt that true "scripting" with a "scripting language" was two things: 1) Most of your functions were linear: low cyclomatic complexity. 2) Functions rarely called into other functions. While "programming" moves away from both of those: 1) Higher cyclomatic complexity is allowed. 2) Functions frequently call into other functions. For instance, I like bash only for scripting. The moment it starts to resemble programming, I tend to switch to Python. However, some people are fine doing a fair amount of "programming" in bash, people who know it really well.
- tetha 2y ago
  Nah, short and single-line functions can be good. Something I'm happy about is if I can create an object to implement some isolated part of the domain in a way that's obviously correct and consistent within itself. For example, currently I'm working on a bit of a backup analyzer to identify different problems, estimate sizes and such. One object in there is the PGBackrestState and it has a whole bunch of one-line methods like total_size_on_disk, full_backup_count, average_incemental_size. Most of these are just one list comprehension. That's nice, readable, correct and stable code - and it makes other code more readable. But some functions in that code base are an implementation of pretty much a flow chart of grabbing information, figuring out the state of the system and eventually dropping into more specific analyzers. This can be a whole bunch of imperative code in a function. And I've tried, but chopping this into smaller functions makes the overall idea and control flow much harder to understand. Sometimes a rough screen length of logic can be easier to understand as well.
  - pbw 2y ago
    I mentioned in another comment pylint’s 50 line limit for methods. So I agree - a well written 50 line method is sometimes better than the same code chopped up. Although a significant factor is if you chopped it up, would there be multiple callers for the new smaller methods? Because that’s probably better than adding flags to your large method to make it behave differently for different callers, increasing its cyclomatic complexity.
SatvikBeri 2y ago
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.
- pbw 2y ago
  I’m not at all familiar with Julia but that sounds interesting. I’ve been thinking recently that with AI we might eventually decouple the style of the source code from the style of the executable code. That is, let you toggle from DOD to OOP in your IDE. The way you can vary the font in your IDE today. Very non-trivial but in the long term could happen.
  - lo0dot0 2y ago
    Can be summarized as automated refactoring between different coding styles.
pbw 2y ago
I think DOD is great and Casey’s optimized version is great. But his claim that OOP inevitably leads to horrible performance is factually wrong. And he’s repeats it over and over even after the viral video. My main goal with the article/video was to debunk this false claim of his. Also, something most people over look is the OOP example in his article is 100% vanilla OOP. There is nothing “clean code” about it. So he’s really railing against OOP and not clean code. My article shows that the impact of the overhead of OOP, but really the impact of the overhead of _anything_, can range from huge to basically zero, depending on the time scales involved. So my main point is you should be very mindful of the time scales involved. But if you want to rule out OOP for non-performance reasons I think that’s fine. All styles have pros and cons, and situations can vary widely. Like for instance the existing style of the project and the skills and preferences of the people involved.
- nateglims 2y ago
  I don't quite follow how you proved it wrong. All the examples seemed to be alternatives to OOP?
- _aavaa_ 2y ago
  > My article shows that the impact of the overhead of OOP ... So my main point is you should be very mindful of the time scales involved. But if the overhead of OOP, as shown both by you and by Casey in his original video, makes up a significant chunk of your computation time it will inevitably lead to bad performance. Once you are mindful of the timescale and realize that OOP is the culprit, your only choice to go faster is to get rid of it.

jpardy 2y ago

In addition to Mike Acton's talk, there is also the "DOD Book": https://www.dataorienteddesign.com/dodbook/ https://www.dataorienteddesign.com/dodbook/

wiseowise 2y ago

> Uncle bob's Clean Code probably feels natural to Java devs. No.

tcfhgj 2y ago

Don't see a problem with one line functions per se, especially if the name of the function helps understanding the code

arp242 2y ago
There no problem with them, and they can often be useful. But there is a problem if all the code is only functions of one or two lines, or when people move things to functions when it just doesn't make much sense, "because it's Best Practice™".
- pbw 2y ago
  Pylint warns if you have “more than X” for a lot things like local variables, number of arguments, number of member variables, etc. For most of these the limits are in the 5 - 9 range but for lines in a function/method the limit is 50 lines. I agree with this. One line functions are okay sometimes but 50 line functions can be fine as well if clear and well written. A lot depends on the cyclomatic complexity: how many loops and branches, how drastically the indentation varies basically. So I disagree with how strenuously Uncle Bob harps on short methods, although paradoxically I do agree many methods in the wild are too long. Most of them grew to be too long because it’s easier to add a few lines to an existing method than to refactor things —- particularly if a code review is required.
  - LorenPechtel 2y ago
    Yup. I would like to keep things on the screen if feasible, but it's really always cyclomatic complexity that matters. A linear flow of lines, I don't care about until I can't see it all at once but you're rarely writing a linear flow of lines.
    - pbw 2y ago
      I always felt that true "scripting" with a "scripting language" was two things: 1) Most of your functions were linear: low cyclomatic complexity. 2) Functions rarely called into other functions. While "programming" moves away from both of those: 1) Higher cyclomatic complexity is allowed. 2) Functions frequently call into other functions. For instance, I like bash only for scripting. The moment it starts to resemble programming, I tend to switch to Python. However, some people are fine doing a fair amount of "programming" in bash, people who know it really well.
tetha 2y ago
Nah, short and single-line functions can be good. Something I'm happy about is if I can create an object to implement some isolated part of the domain in a way that's obviously correct and consistent within itself. For example, currently I'm working on a bit of a backup analyzer to identify different problems, estimate sizes and such. One object in there is the PGBackrestState and it has a whole bunch of one-line methods like total_size_on_disk, full_backup_count, average_incemental_size. Most of these are just one list comprehension. That's nice, readable, correct and stable code - and it makes other code more readable. But some functions in that code base are an implementation of pretty much a flow chart of grabbing information, figuring out the state of the system and eventually dropping into more specific analyzers. This can be a whole bunch of imperative code in a function. And I've tried, but chopping this into smaller functions makes the overall idea and control flow much harder to understand. Sometimes a rough screen length of logic can be easier to understand as well.
- pbw 2y ago
  I mentioned in another comment pylint’s 50 line limit for methods. So I agree - a well written 50 line method is sometimes better than the same code chopped up. Although a significant factor is if you chopped it up, would there be multiple callers for the new smaller methods? Because that’s probably better than adding flags to your large method to make it behave differently for different callers, increasing its cyclomatic complexity.

SatvikBeri 2y ago

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.

pbw 2y ago
I’m not at all familiar with Julia but that sounds interesting. I’ve been thinking recently that with AI we might eventually decouple the style of the source code from the style of the executable code. That is, let you toggle from DOD to OOP in your IDE. The way you can vary the font in your IDE today. Very non-trivial but in the long term could happen.
- lo0dot0 2y ago
  Can be summarized as automated refactoring between different coding styles.

pbw 2y ago

I think DOD is great and Casey’s optimized version is great. But his claim that OOP inevitably leads to horrible performance is factually wrong. And he’s repeats it over and over even after the viral video. My main goal with the article/video was to debunk this false claim of his. Also, something most people over look is the OOP example in his article is 100% vanilla OOP. There is nothing “clean code” about it. So he’s really railing against OOP and not clean code. My article shows that the impact of the overhead of OOP, but really the impact of the overhead of _anything_, can range from huge to basically zero, depending on the time scales involved. So my main point is you should be very mindful of the time scales involved. But if you want to rule out OOP for non-performance reasons I think that’s fine. All styles have pros and cons, and situations can vary widely. Like for instance the existing style of the project and the skills and preferences of the people involved.

nateglims 2y ago
I don't quite follow how you proved it wrong. All the examples seemed to be alternatives to OOP?
_aavaa_ 2y ago
> My article shows that the impact of the overhead of OOP ... So my main point is you should be very mindful of the time scales involved. But if the overhead of OOP, as shown both by you and by Casey in his original video, makes up a significant chunk of your computation time it will inevitably lead to bad performance. Once you are mindful of the timescale and realize that OOP is the culprit, your only choice to go faster is to get rid of it.