[flagged]
Semantic compression (2014)
21–30 of 33 posts
Re: Semantic compression (2014)
#22Earlier quoted context omitted.
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 an…
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.
Re: Semantic compression (2014)
#23I 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.
Re: Semantic compression (2014)
#24The 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…
> 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.
Re: Semantic compression (2014)
#25So 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.
Re: Semantic compression (2014)
#26It'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.
Re: Semantic compression (2014)
#27It'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.
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.
Re: Semantic compression (2014)
#28So 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.
Re: Semantic compression (2014)
#29It'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.
Re: Semantic compression (2014)
#30Earlier quoted context omitted.
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 an…
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…
> 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.