4 ms·

Fun fact. Software you routinely use, like Linux and Postgres, is written in the same "spaghetti" style. I guess the Clean Code people who implement CRUD featur

Fun fact. Software you routinely use, like Linux and Postgres, is written in the same "spaghetti" style. I guess the Clean Code people who implement CRUD features for a living are better programmers than the ones writing operating systems and databases. > Most of us work in an environment where surprising - even astonishing - customer requirements are often discovered during development and maintenance. Another fun fact. The author of the video works in an environment where rapid iteration is absolutely vital. I'd pay good money to see a TV show where his style of programming ("spaghetti", as you claim) run laps around your "Clean Code". Because it would. For example, he wrote a terminal emulator in a weekend to prove that Microsoft doesn't have a clue about how to write code (I assume they also have many Clean Code people, and that it would take them about 6 months to write a terminal emulator from scratch). The reason why this video mentions performance is probably because 1) the author has a course on performance and 2) it's something you can objectively measure. If it were me, I'd not even bring performance into discussion, I'd just say that "Clean Code" significantly hurts readability and editability (and thus maintenance). But then you jump in to say that the non-Clean Code version is "an unmaintainable mess", and then we go around in circles. Which is probably why performance is his main point.

tialaramex 4y ago
> I'd pay good money to see a TV show where his style of programming ("spaghetti", as you claim) run laps around your "Clean Code". You'd like to pay money to be assured that you're right? I prefer to have an informed opinion based on actually trying stuff out and measuring†, I also find that as a result I don't feel the need to pay for validation. > For example, he wrote a terminal emulator in a weekend to prove that Microsoft doesn't have a clue about how to write code So, your thesis is that writing a terminal emulator - software which is pretending to be hardware that existed 40+ years ago, shows that this person is great at handling surprising requirements changes during development ? An insistence that the only thing we can measure is performance and specifically speed and therefore that's the only thing that matters is nonsense. It's just that this technique does so poorly when judged on maintainability that it's no contest. Try it, first add the hollow box example shape, in the Clean Code this is very easy and we'll notice immediately it's de-coupled, colleagues working with abstract shapes don't care at all about our Hollow Box shape, it all just works with the abstract APIs. The less-clean switch approach is a little bit hairier now, but it's very possible although we may notice now our objects are all bigger again, even though perhaps few are hollow boxes, they're all bigger as they all need to track the possible state of a hollow box. So that's actually a significant performance degradation for some applications in our supposedly "high performance" solution... The table-driven approach needs a rewrite though, the F*W*H simplicity doesn't apply any more, there are a few "minimalist" approaches, all of them awful compromises waiting for the other shoe to drop - so perhaps a big bang rewrite is called for. Ouch. Now, having learned from our hollow box experience, let's add Regular Star Polygons next. These are pretty interesting shapes - but we're shape classes so no reason we can't handle this, the stars have a defined area and a defined number of vertices ("corners"). But while the Clean Code here is very tractable, the dirtier approaches start to hurt pretty bad now. Notice that under Clean Code the exact implementation of Regular Star Polygons doesn't affect anybody else, their code all still works regardless. For example maybe we should sub-class popular examples like the 5/2 and 6/2 rather than taking p and q parameters, doing this works fine under Clean Code, since it's nobody else's business. † EtA: One of the most important innovations in years has been Godbolt.org, Matt Godbolt originally worked on this tool to examine exactly this sort of question, it's one that comes up early in the talk you liked - can we safely use actual C++ iterators? Wouldn't an old-fashioned for loop be faster in some cases? Matt's answer was "Yes", you can use iterators, the iterators produce exactly the same machine code and the tool he used to demonstrate that evolved into Compiler Explorer, the godbolt.org site today.
- Tomis02 4y ago
  > You'd like to pay money to be assured that you're right? I know I'm right, I'd pay money to see the embarrassment of the presumptuous Clean Code people who think that they can write maintainable code better than those who write software that matters (like Linux or Postgres, as mentioned before). > So, your thesis is that writing a terminal emulator - software which is pretending to be hardware that existed 40+ years ago, shows that this person is great at handling surprising requirements changes during development ? No. My thesis is that this guy can write code better than people who are supposed to be in the top 1% of the developers (well, it's Microsoft, not a web app sweatshop). He works on games, where you not only have to iterate very quickly but you also may need to completely change direction halfway through the project. They can't have an "unmaintainable mess", otherwise they're not shipping the game, so your premise is wrong from the start. Also, games are much more complicated to program than the average Clean Code Crud app project that Uncle Bob bikesheds on. > An insistence that the only thing we can measure is performance and specifically speed and therefore that's the only thing that matters is nonsense Nobody said that, how are you coming up with this stuff? The point Casey was making is that you're paying a significant performance penalty (speed, in this example) by doing Clean Code, which is true. You're denying yourself very basic performance techniques if you close your eyes and pretend to not see the internals of each shape. > Try it, first add the hollow box example shape, What if you don't have to? What if those are all the shapes you have to support? But there's ten billion shapes, you chose to do Clean Code and now you have slow code for zero benefit. Ouch. On the other hand, if you want to add more shapes then the problem you're solving changed, and therefore you need to change the code (not really the tragedy you're making it out to be). I don't get this obsession, "code should change as little as possible"; it's actually a "careful what you wish for" moment because class hierarchies tend to become very rigid and difficult to change. Good luck making significant changes when your 100k+ loc program relies on a particular class hierarchy being in place. > the iterators produce exactly the same machine code That's great but it seems you're trying really hard to interpret Casey's video in bad faith. The way I understood it, he used an old fashioned for loop to avoid detracting from the main discussion, as not everyone knows what are the internals of STL iterators and how they translate to machine code.
  - 4y ago

tialaramex 4y ago

> I'd pay good money to see a TV show where his style of programming ("spaghetti", as you claim) run laps around your "Clean Code". You'd like to pay money to be assured that you're right? I prefer to have an informed opinion based on actually trying stuff out and measuring†, I also find that as a result I don't feel the need to pay for validation. > For example, he wrote a terminal emulator in a weekend to prove that Microsoft doesn't have a clue about how to write code So, your thesis is that writing a terminal emulator - software which is pretending to be hardware that existed 40+ years ago, shows that this person is great at handling surprising requirements changes during development ? An insistence that the only thing we can measure is performance and specifically speed and therefore that's the only thing that matters is nonsense. It's just that this technique does so poorly when judged on maintainability that it's no contest. Try it, first add the hollow box example shape, in the Clean Code this is very easy and we'll notice immediately it's de-coupled, colleagues working with abstract shapes don't care at all about our Hollow Box shape, it all just works with the abstract APIs. The less-clean switch approach is a little bit hairier now, but it's very possible although we may notice now our objects are all bigger again, even though perhaps few are hollow boxes, they're all bigger as they all need to track the possible state of a hollow box. So that's actually a significant performance degradation for some applications in our supposedly "high performance" solution... The table-driven approach needs a rewrite though, the F*W*H simplicity doesn't apply any more, there are a few "minimalist" approaches, all of them awful compromises waiting for the other shoe to drop - so perhaps a big bang rewrite is called for. Ouch. Now, having learned from our hollow box experience, let's add Regular Star Polygons next. These are pretty interesting shapes - but we're shape classes so no reason we can't handle this, the stars have a defined area and a defined number of vertices ("corners"). But while the Clean Code here is very tractable, the dirtier approaches start to hurt pretty bad now. Notice that under Clean Code the exact implementation of Regular Star Polygons doesn't affect anybody else, their code all still works regardless. For example maybe we should sub-class popular examples like the 5/2 and 6/2 rather than taking p and q parameters, doing this works fine under Clean Code, since it's nobody else's business. † EtA: One of the most important innovations in years has been Godbolt.org, Matt Godbolt originally worked on this tool to examine exactly this sort of question, it's one that comes up early in the talk you liked - can we safely use actual C++ iterators? Wouldn't an old-fashioned for loop be faster in some cases? Matt's answer was "Yes", you can use iterators, the iterators produce exactly the same machine code and the tool he used to demonstrate that evolved into Compiler Explorer, the godbolt.org site today.

Tomis02 4y ago
> You'd like to pay money to be assured that you're right? I know I'm right, I'd pay money to see the embarrassment of the presumptuous Clean Code people who think that they can write maintainable code better than those who write software that matters (like Linux or Postgres, as mentioned before). > So, your thesis is that writing a terminal emulator - software which is pretending to be hardware that existed 40+ years ago, shows that this person is great at handling surprising requirements changes during development ? No. My thesis is that this guy can write code better than people who are supposed to be in the top 1% of the developers (well, it's Microsoft, not a web app sweatshop). He works on games, where you not only have to iterate very quickly but you also may need to completely change direction halfway through the project. They can't have an "unmaintainable mess", otherwise they're not shipping the game, so your premise is wrong from the start. Also, games are much more complicated to program than the average Clean Code Crud app project that Uncle Bob bikesheds on. > An insistence that the only thing we can measure is performance and specifically speed and therefore that's the only thing that matters is nonsense Nobody said that, how are you coming up with this stuff? The point Casey was making is that you're paying a significant performance penalty (speed, in this example) by doing Clean Code, which is true. You're denying yourself very basic performance techniques if you close your eyes and pretend to not see the internals of each shape. > Try it, first add the hollow box example shape, What if you don't have to? What if those are all the shapes you have to support? But there's ten billion shapes, you chose to do Clean Code and now you have slow code for zero benefit. Ouch. On the other hand, if you want to add more shapes then the problem you're solving changed, and therefore you need to change the code (not really the tragedy you're making it out to be). I don't get this obsession, "code should change as little as possible"; it's actually a "careful what you wish for" moment because class hierarchies tend to become very rigid and difficult to change. Good luck making significant changes when your 100k+ loc program relies on a particular class hierarchy being in place. > the iterators produce exactly the same machine code That's great but it seems you're trying really hard to interpret Casey's video in bad faith. The way I understood it, he used an old fashioned for loop to avoid detracting from the main discussion, as not everyone knows what are the internals of STL iterators and how they translate to machine code.
- 4y ago