3 ms·

I think Martin has a lot more to answer for as far as the sorry state of software today goes. Watching his discussion with Casey Muratori on GitHub last year wa

by _hao 3y ago

I think Martin has a lot more to answer for as far as the sorry state of software today goes. Watching his discussion with Casey Muratori on GitHub last year was great. Not many people saw it, but boy does he compare poorly to a truly capable and knowledgeable programmer - https://github.com/unclebob/cmuratori-discussion https://github.com/unclebob/cmuratori-discussion

elteto 3y ago
I started reading this and honestly don’t see the part where he “compares poorly” against Muratori. And disclaimer, I know more about Casey and his work than I know about “Uncle Bob”. If anything, Bob managed to explain himself very well and defend his point of view, which is, “context matters and programmer cycles are more important than CPU cycles in the majority of contexts”. I think this is something we could all agree on, no?
- _gabe_ 3y ago
  > “context matters and programmer cycles are more important than CPU cycles in the majority of contexts”. I think this is something we could all agree on, no? I don’t think people agree on this (I don’t at least). I like the story falsely attributed to Steve Jobs about how saving a user 1 second will save hundreds of years or whatever. From that perspective, programmer cycles are way less important than CPU cycles because every CPU cycle you save has a multiplicative effect depending on how many users you serve. And how true is that today when you have thousands of large business apps depending on one cloud service provider. The compounding effects of saving CPU cycles in every level of the stack has never been higher than it is today.
  - mrkeen 3y ago
    This had a very narrow context - so you're right to push back on parent applying it generally. But Martin was originally saying that a program with DI will not be as fast as a program without DI ... i.e., interfaces! When was the last time you were writing a program and thought that putting a class behind an interface would slow things down too much?
mrkeen 3y ago
What harmful info is Martin putting out there?
dharmon 3y ago
I generally have a negative opinion of Martin, but did we read the same discussion? Martin was very gracious in letting many points slide (points where he was correct!), and was generously willing to end the conversation at a sort-of draw when it was clear that Muratori was not really prepared to discuss things at a detailed level (It was obvious to me from the start that Muratori thought "dynamic polymorphism" just meant deep hierarchies of inheritance, a la early C++, Martin realized this later and I think that was the first inkling that he was wasting his time). Muratori was even wasting his time arguing against programmer time _in general_ is less valuable than machine time? And doesn't understand that LLVM is an extremely specialized piece of software, from which general software engineering practices should not be extracted?
- GuestHNUser 3y ago
  > It was obvious to me from the start that Muratori thought "dynamic polymorphism" just meant deep hierarchies of inheritance Inheritance hierarchies aren't exclusively what he meant though. Interfaces and the whole 'prefer composition over inheritance' style of programming has the same fundamental problem Muratori is getting at: both inherently constrain a program's structure for, what he argues (and I agree with), has no benefit to the program's performance or the programmer's time. In fact, he argues that the constraints imposed by the use of inheritance/interfaces only slow programmers down. His raw device driver example, in pt2 of their conversation, illustrates the advantage of procedural code over inheritance/interfaces. His API requires users to provide a function pointer that will be called whenever an event is raised. This API user is expected to switch over the enum values that they care to implement. This design is better than an interface that requires its members to implement read(), and write() functions because it is both more performant (no vtable overhead + compilers can make more aggressive optimizations) and more flexible (a new event can be added to the enum without requiring all the old code to be updated if they don't need to handle the new event type).

by _hao 3y ago

elteto 3y ago

I started reading this and honestly don’t see the part where he “compares poorly” against Muratori. And disclaimer, I know more about Casey and his work than I know about “Uncle Bob”. If anything, Bob managed to explain himself very well and defend his point of view, which is, “context matters and programmer cycles are more important than CPU cycles in the majority of contexts”. I think this is something we could all agree on, no?

_gabe_ 3y ago
> “context matters and programmer cycles are more important than CPU cycles in the majority of contexts”. I think this is something we could all agree on, no? I don’t think people agree on this (I don’t at least). I like the story falsely attributed to Steve Jobs about how saving a user 1 second will save hundreds of years or whatever. From that perspective, programmer cycles are way less important than CPU cycles because every CPU cycle you save has a multiplicative effect depending on how many users you serve. And how true is that today when you have thousands of large business apps depending on one cloud service provider. The compounding effects of saving CPU cycles in every level of the stack has never been higher than it is today.
- mrkeen 3y ago
  This had a very narrow context - so you're right to push back on parent applying it generally. But Martin was originally saying that a program with DI will not be as fast as a program without DI ... i.e., interfaces! When was the last time you were writing a program and thought that putting a class behind an interface would slow things down too much?

mrkeen 3y ago

What harmful info is Martin putting out there?

dharmon 3y ago

I generally have a negative opinion of Martin, but did we read the same discussion? Martin was very gracious in letting many points slide (points where he was correct!), and was generously willing to end the conversation at a sort-of draw when it was clear that Muratori was not really prepared to discuss things at a detailed level (It was obvious to me from the start that Muratori thought "dynamic polymorphism" just meant deep hierarchies of inheritance, a la early C++, Martin realized this later and I think that was the first inkling that he was wasting his time). Muratori was even wasting his time arguing against programmer time _in general_ is less valuable than machine time? And doesn't understand that LLVM is an extremely specialized piece of software, from which general software engineering practices should not be extracted?

GuestHNUser 3y ago
> It was obvious to me from the start that Muratori thought "dynamic polymorphism" just meant deep hierarchies of inheritance Inheritance hierarchies aren't exclusively what he meant though. Interfaces and the whole 'prefer composition over inheritance' style of programming has the same fundamental problem Muratori is getting at: both inherently constrain a program's structure for, what he argues (and I agree with), has no benefit to the program's performance or the programmer's time. In fact, he argues that the constraints imposed by the use of inheritance/interfaces only slow programmers down. His raw device driver example, in pt2 of their conversation, illustrates the advantage of procedural code over inheritance/interfaces. His API requires users to provide a function pointer that will be called whenever an event is raised. This API user is expected to switch over the enum values that they care to implement. This design is better than an interface that requires its members to implement read(), and write() functions because it is both more performant (no vtable overhead + compilers can make more aggressive optimizations) and more flexible (a new event can be added to the enum without requiring all the old code to be updated if they don't need to handle the new event type).