The intro has nothing to do with the rest of the article, really. The author claims it does at the end, but it's just trashing OOP for fun (the author even says this).
OOP is fine. And DRY (what the core idea of the article is getting at) applies in OOP paradigms as much any another. The arguments the author makes are orthogonal to OOP.
The author seems to not enjoy planning before writing code, which I guess is more necessary for OOP than other paradigms?
> The author seems to not enjoy planning before writing code
Or the author's experience (which is extensive) has led to the conclusion that all that planning you want to do at the beginning rarely gets you the proper abstractions.
It's really weird when the blogger assumes they know exactly what I do and think, here that I think of a class hierarchy as the first thing when writing a C++ program.
I suppose they're going for the "wow, are you God?" effect, but when it's a miss, it just makes them look silly.
The kind of thinking that the blogger describes was highly pervasive in enterprise circles in the late 90s and early aughts. There was a cult-like following of some of the tenets of object oriented programming - that's where the whole "Java = overly verbose spaghetti" reputation was born.
It doesn't help that OOP is still frequently taught in a similar style; not necessarily with UML diagrams, but with inheritance hierarchies that are often based on physical objects (i.e. an Animal class, with Cat and Dog subclasses). This doesn't necessarily reflect current OOP's actual usage (tending towards less use of inheritance, as well as classes that represent more abstract entities like UI components), but it's the first exposure of OOP for a lot of people.
When I read or listen to Muratori, I almost certainly agree with most of the substance of what he is saying. It's just that he has the most disagreeable way of making his point.
I think it's helpful to think of nearly all the content produced by Muratori and Blow as a branding exercise. They want you to think they are enfant terrible style geniuses who represent the vanguard of the profession. As silly as their strawmen are, this frame of "civilization is in decline because it fails to recognize my unique genius" is much more silly, and makes each video/rant seem both one note and self aggrandizing.
I was actually in the school of thought that this article describes until I read and worked through the book How to Design Programs [0]. The rest is upto you to judge.
> I was actually in the school of thought that this article describes until I read and worked through the book How to Design Programs
What distinguishes the approach from what is presented in this blog post, can you provide a summary for those of us who haven't read the book? I am sincerely interested.
The book utilises a series of Scheme based teaching languages to teach about how to write functions for increasingly complicated data types. The language levels produce meaningful error messages for programmers of that particular level and goes on adding language features as you progress through the book.
The book furthermore teaches a design recipe which comes in handy when you are stuck with a problem. Basically it teaches you to write examples first so that you understand the problem instead of jumping onto the editor to write code first. The examples help you structure your data. The rest of the code follows from it.
A page-long strawman isn't a great way to start an article. I also disagree with the author's claim that refactoring is ridiculous or different, but like the author I'm not going to elaborate.
What's the strawman? This way of thinking is taught in universities around the world. And it doesn't stay there. I personally know people who approach problems like this.
At least in my social bubble, composition over inheritance has been the more popular guideline for two decades.
Instead of a Manager class inheriting Employee and Contractor (which in turn inherit Person, which in turn may inherit other classes...), you'd separate employee and contractor into traits/interfaces and define distinct manager classes that implement the two traits. Of course, ultimately it's all classes and inheritance in C++ because there are no traits, but it's organized differently.
He's not arguing about how common it is in practice for people to choose inheritance vs composition. This line seems to make that pretty clear:
> But despite the fact that many programmers out there have gone through bad phases like this and eventually come to smart conclusions about how to actually write good code efficiently, it seems that the landscape of educational materials out there still overwhelmingly falls into the “objectively bad” category.
So his frustration here is that there's tons of educational material that focuses on inheritance even when that's not what most experienced programmers are doing.
> So his frustration here is that there's tons of educational material that focuses on inheritance even when that's not what most experienced programmers are doing.
His frustration is pretty clearly that OOP, as a whole, whether by composition or inheritance, is "a load of horseshit" in his words.
The introduction describes encountering awkwardness during modeling in OOP, which definitely does happen. But I’m not convinced that a payroll system written in C++ in the style described by the post is going to be a better solution.
There is a short mention of “refactoring” and how it is a bad name, I’m not sure why, just read the article in 3mins.
TL;DR: start with the complex things, deduplicate code and use proper data structures once you have working code with multiple use cases.
The only thing the word “refactoring” tells me is that you’re rearranging code without changing functionality. It doesn’t tell me why you’re doing it. You could be doing it for all sorts of reasons: to extract part of the code into a separate library, to route around dead code so it can be excised later, to enable a performance optimisation, or to allow a new feature.
What’s going on in this article is refactoring towards a very specific goal. That goal is reaching an architectural style that could also have been achieved earlier in the development process, and it’s that style that is, AIUI, the point of the article.
I think semantic compression is achieved by using a denser more expressive language, some languages can express the same activity in far fewer lines of code.
Personally I find the denser code, harder to read, which I think also makes sense, since it contains more meaning in less space.
If you are writing code, perhaps in python, and you keep following your editors instructions to refactor it, you end up with far fewer repeated lines of code, and lots of small reused functions, you are actually doing manual code compression.
I have always wondered why, if editors are so smart, they don't have a 'compress this project' button, which does all that for you.
At that point it's giving you a foreign code base that's hard to reason about until you grok what it is it has done.
Prompting you to make the changes allows you to cognitively keep up in lockstep with the code changes. Further, it has no concept of your present/future intent, so perhaps not all of its suggestions apply.
All he wanted to do was have some buttons that react to the mouse and run code. At this point, such a thing should be a language primitive like floating point.
Which, coincidentally, is also the advice paired with DRY by most competent people (including in the main book people seem to have learned DRY from, The Pragmatic Programmer). Apply it after repetitions, not before.
So I guess he thinks that classes are great as long as there is never any inheritance? And so if you do that then it doesn't count as object oriented programming or something. Especially if you give it a new name like "semantic compression". Lol.
I think the newish thing is traits such as in Rust.
Yes. It's increasingly common in big C++ code bases (Unreal for example) to prefer interfaces, templates and composition over inheritance, though it's mostly found in newer code. Unreal is still fairly OOP since it is decades old.
Of course, there is some object-orientedness to it, the author even calls part of his new code "objects". I guess some people would call that OOP, but it's certainly not traditional OOP.
Rust does a really nice job of making that the first obvious thing to reach for (simple structs, traits and generics), and making the slower stuff like dyn traits (v-table indirection) more annoying and less desired. Reducing indirection and abstractions makes it easier to reason about code.
> Normally, I would probably not make these member functions, but since The Witness is a more C++-ish codebase than my own, I thought it was more consistent with the style (and I don’t have a strong preference either way)
My interpretation of this is that normally he'd make plain C structs and functions that operate on them. So quite far from anything people would normally describe or think of as object oriented.
The intro has nothing to do with the rest of the article, really. The author claims it does at the end, but it's just trashing OOP for fun (the author even says this).
OOP is fine. And DRY (what the core idea of the article is getting at) applies in OOP paradigms as much any another. The arguments the author makes are orthogonal to OOP.
The author seems to not enjoy planning before writing code, which I guess is more necessary for OOP than other paradigms?
> The author seems to not enjoy planning before writing code
Or the author's experience (which is extensive) has led to the conclusion that all that planning you want to do at the beginning rarely gets you the proper abstractions.
It's really weird when the blogger assumes they know exactly what I do and think, here that I think of a class hierarchy as the first thing when writing a C++ program.
I suppose they're going for the "wow, are you God?" effect, but when it's a miss, it just makes them look silly.
The kind of thinking that the blogger describes was highly pervasive in enterprise circles in the late 90s and early aughts. There was a cult-like following of some of the tenets of object oriented programming - that's where the whole "Java = overly verbose spaghetti" reputation was born.
It doesn't help that OOP is still frequently taught in a similar style; not necessarily with UML diagrams, but with inheritance hierarchies that are often based on physical objects (i.e. an Animal class, with Cat and Dog subclasses). This doesn't necessarily reflect current OOP's actual usage (tending towards less use of inheritance, as well as classes that represent more abstract entities like UI components), but it's the first exposure of OOP for a lot of people.
When I read or listen to Muratori, I almost certainly agree with most of the substance of what he is saying. It's just that he has the most disagreeable way of making his point.
I think it's helpful to think of nearly all the content produced by Muratori and Blow as a branding exercise. They want you to think they are enfant terrible style geniuses who represent the vanguard of the profession. As silly as their strawmen are, this frame of "civilization is in decline because it fails to recognize my unique genius" is much more silly, and makes each video/rant seem both one note and self aggrandizing.
I was actually in the school of thought that this article describes until I read and worked through the book How to Design Programs [0]. The rest is upto you to judge.
[0] https://htdp.org/
Edit: I would love others, who have read the above mentioned book, to weigh in with your anecdotes.
> I was actually in the school of thought that this article describes until I read and worked through the book How to Design Programs
What distinguishes the approach from what is presented in this blog post, can you provide a summary for those of us who haven't read the book? I am sincerely interested.
The book utilises a series of Scheme based teaching languages to teach about how to write functions for increasingly complicated data types. The language levels produce meaningful error messages for programmers of that particular level and goes on adding language features as you progress through the book.
The book furthermore teaches a design recipe which comes in handy when you are stuck with a problem. Basically it teaches you to write examples first so that you understand the problem instead of jumping onto the editor to write code first. The examples help you structure your data. The rest of the code follows from it.
A page-long strawman isn't a great way to start an article. I also disagree with the author's claim that refactoring is ridiculous or different, but like the author I'm not going to elaborate.
What's the strawman? This way of thinking is taught in universities around the world. And it doesn't stay there. I personally know people who approach problems like this.
At least in my social bubble, composition over inheritance has been the more popular guideline for two decades.
Instead of a Manager class inheriting Employee and Contractor (which in turn inherit Person, which in turn may inherit other classes...), you'd separate employee and contractor into traits/interfaces and define distinct manager classes that implement the two traits. Of course, ultimately it's all classes and inheritance in C++ because there are no traits, but it's organized differently.
He's not arguing about how common it is in practice for people to choose inheritance vs composition. This line seems to make that pretty clear:
> But despite the fact that many programmers out there have gone through bad phases like this and eventually come to smart conclusions about how to actually write good code efficiently, it seems that the landscape of educational materials out there still overwhelmingly falls into the “objectively bad” category.
So his frustration here is that there's tons of educational material that focuses on inheritance even when that's not what most experienced programmers are doing.
> So his frustration here is that there's tons of educational material that focuses on inheritance even when that's not what most experienced programmers are doing.
His frustration is pretty clearly that OOP, as a whole, whether by composition or inheritance, is "a load of horseshit" in his words.
Semantic compression is such a cool shorthand.
This article really helped me put things I had believed for years into words when I first read it. It's pretty amazing.
The introduction describes encountering awkwardness during modeling in OOP, which definitely does happen. But I’m not convinced that a payroll system written in C++ in the style described by the post is going to be a better solution.
This is from 2014 (it felt awfully familiar when it got to the code samples) but submitted under the title "Semantic Compression" or other variations:
https://news.ycombinator.com/item?id=17090319 - May 17, 2018 (41 comments)
There are others with 1-2 comments but no other discussions beyond that that I can find.
How's this different from just refactoring? Why the fancy name?
There is a short mention of “refactoring” and how it is a bad name, I’m not sure why, just read the article in 3mins. TL;DR: start with the complex things, deduplicate code and use proper data structures once you have working code with multiple use cases.
The only thing the word “refactoring” tells me is that you’re rearranging code without changing functionality. It doesn’t tell me why you’re doing it. You could be doing it for all sorts of reasons: to extract part of the code into a separate library, to route around dead code so it can be excised later, to enable a performance optimisation, or to allow a new feature.
What’s going on in this article is refactoring towards a very specific goal. That goal is reaching an architectural style that could also have been achieved earlier in the development process, and it’s that style that is, AIUI, the point of the article.
I think semantic compression is achieved by using a denser more expressive language, some languages can express the same activity in far fewer lines of code. Personally I find the denser code, harder to read, which I think also makes sense, since it contains more meaning in less space. If you are writing code, perhaps in python, and you keep following your editors instructions to refactor it, you end up with far fewer repeated lines of code, and lots of small reused functions, you are actually doing manual code compression. I have always wondered why, if editors are so smart, they don't have a 'compress this project' button, which does all that for you.
At that point it's giving you a foreign code base that's hard to reason about until you grok what it is it has done.
Prompting you to make the changes allows you to cognitively keep up in lockstep with the code changes. Further, it has no concept of your present/future intent, so perhaps not all of its suggestions apply.
All he wanted to do was have some buttons that react to the mouse and run code. At this point, such a thing should be a language primitive like floating point.
Jargon abstraction
TL;DR: DRY
Nice read, though. Very approachable.
Yep, but with the added condition of “don’t DRY pre-maturely, that is, before you have duplicated code”.
Which, coincidentally, is also the advice paired with DRY by most competent people (including in the main book people seem to have learned DRY from, The Pragmatic Programmer). Apply it after repetitions, not before.
So I guess he thinks that classes are great as long as there is never any inheritance? And so if you do that then it doesn't count as object oriented programming or something. Especially if you give it a new name like "semantic compression". Lol.
I think the newish thing is traits such as in Rust.
Yes. It's increasingly common in big C++ code bases (Unreal for example) to prefer interfaces, templates and composition over inheritance, though it's mostly found in newer code. Unreal is still fairly OOP since it is decades old.
Of course, there is some object-orientedness to it, the author even calls part of his new code "objects". I guess some people would call that OOP, but it's certainly not traditional OOP.
Rust does a really nice job of making that the first obvious thing to reach for (simple structs, traits and generics), and making the slower stuff like dyn traits (v-table indirection) more annoying and less desired. Reducing indirection and abstractions makes it easier to reason about code.
From the article:
> Normally, I would probably not make these member functions, but since The Witness is a more C++-ish codebase than my own, I thought it was more consistent with the style (and I don’t have a strong preference either way)
My interpretation of this is that normally he'd make plain C structs and functions that operate on them. So quite far from anything people would normally describe or think of as object oriented.