Semantic Compression (2014)(caseymuratori.com)
caseymuratori.com
Semantic Compression (2014)
https://caseymuratori.com/blog_0015
8 comments
This is exactly how I write code. I never engineer anything until I have to. I don't try to get rid of code duplication until it works. And I try to be as "least clever" as possible.
I'm the same way. Underengineering is so much easier to fix than overengineering.
[deleted]
And yet somehow in the enterprise software you always find 'EntityModelFactoryProvider' or 'BusinessRelationValidationService'
One of my favorite articles of all time.
It helped crystallize a number of concepts I understood but hadn’t been able to fully realize in the face of the prevailing OOP trends of the time.
It was the permission I needed to buck those trends.
It helped crystallize a number of concepts I understood but hadn’t been able to fully realize in the face of the prevailing OOP trends of the time.
It was the permission I needed to buck those trends.
Well, one might think it's not hard to predict that you will have to use buttons in the game editor more than once...
Despite being a systems level programming expert, his criticism of OOP is utterly otherworldly terrible.
There are tons of problems where you don't need inheritance and can just use composition but let's just assume that was too impure as well. Then you can just use OOP ideas like encapsulation to map the data and the methods working on the data together. If I have a vector class, it makes sense that I overload the + operator to do things like v3 = v1 + v2.
That's orders of magnitude better than saying v3 = vector_add(v1, v2). Free functions instead of encapsulation are ridiculous. car_print(car) is a lot crapper than just saying car.print(). Hiding implementation details is how we get to build nice abstract things where we don't have to worry about implementation details. He is a low-level programmer through and through and can't even imagine why someone may prefer or enjoy a more abstract way of programming.
For more on this Ruby has excellent OOP support and it has permitted people to create insane amount of value. Rails for example is phenomenal. If you don't throw the baby with the bathwater OOP can be a phenomenal technique for organizing large codebases.
There are tons of problems where you don't need inheritance and can just use composition but let's just assume that was too impure as well. Then you can just use OOP ideas like encapsulation to map the data and the methods working on the data together. If I have a vector class, it makes sense that I overload the + operator to do things like v3 = v1 + v2.
That's orders of magnitude better than saying v3 = vector_add(v1, v2). Free functions instead of encapsulation are ridiculous. car_print(car) is a lot crapper than just saying car.print(). Hiding implementation details is how we get to build nice abstract things where we don't have to worry about implementation details. He is a low-level programmer through and through and can't even imagine why someone may prefer or enjoy a more abstract way of programming.
For more on this Ruby has excellent OOP support and it has permitted people to create insane amount of value. Rails for example is phenomenal. If you don't throw the baby with the bathwater OOP can be a phenomenal technique for organizing large codebases.
Not trying to praise OOP at all here but notice a couple of things;
- You’re not dealing with persistence. No DB, no migration headaches, no downtime requirements, etc. Constraints entirely devoid of business requirements.
- You still arrived at the same level of indirection you belabored.
- You worked off of an established project that didn’t go off on any tangents. Building bottom up, depending on how much foresight you have, easily leads to the kind of mess that you cannot semantically compress without rewriting from scratch. In many cases, especially if working on projects with multiple people, those reusable patterns will be incredibly difficult to spot due to the mess surrounding the implementations.
You’re definitely on the right track, but for one it’s not an xor choice which approach you take (semantic compression or OOP), secondly, semantic compression is not as simple as it was made out here to be, and lastly, businesses do not build bottom up.
- You’re not dealing with persistence. No DB, no migration headaches, no downtime requirements, etc. Constraints entirely devoid of business requirements.
- You still arrived at the same level of indirection you belabored.
- You worked off of an established project that didn’t go off on any tangents. Building bottom up, depending on how much foresight you have, easily leads to the kind of mess that you cannot semantically compress without rewriting from scratch. In many cases, especially if working on projects with multiple people, those reusable patterns will be incredibly difficult to spot due to the mess surrounding the implementations.
You’re definitely on the right track, but for one it’s not an xor choice which approach you take (semantic compression or OOP), secondly, semantic compression is not as simple as it was made out here to be, and lastly, businesses do not build bottom up.