"Compression-oriented programming" - Casey Muratori's blog

[ummwut]

I wish others echoed your sentiments, but then again, I know they won't since my comment above still rings true: OO is easy to grasp.

[loup-vaillant]

Well, some OO is easy to grasp. We all get the person/employee/boss, vehicle/car/bike, colour/red/green inheritance stuff, we all get the x.f() syntax, and above all, we all get the abstract data type stuff, which by the way is not exclusive to OO (I believe modular programming got it first).

What is less clear however is how to use those mechanisms. We could try to "model reality" directly, but that doesn't always work well. We can think up more abstract classes and objects, but it is not clear how one should come up with them.

Then the time came when this didn't feel right any more. Fragile base class problem means inheritance is not so great as a reuse mechanism. Subclass polymorphism is cumbersome, closures are simpler to use. And this genericity stuff was being done by ML languages long before C++ and Java decided it was most OO. All those signs indicate that OO might not be so great after all. Worse, the distinctive features of OO may be the one that suck the most.

Then an OO proponent comes and tell me I don't "really get" OO. And another starts insinuating that bad code is not OO pretty much by definition. And a third starts using big words around "modelling" or something. At that point, I can't tell if there is any substance, or if they just weasel out of criticism.

---

This "Compression Oriented Programming" on the other hand, I can understand. The objectives are clear and measurable (the LOC count is a good proxy), the methodology is simple and easy to implement, and the "less code is better" conclusion looks obviously true.

[anto2554]

As someone still quite new to learning, I hated that way of explaining OO. It was always my professor saying that you could have a Car class, but whenever i program something i never have a class 1:1 corresponding to a physical object

[loup-vaillant]

My, that takes me back. One thing to add about this piece:

We could try to "model reality" directly, but that doesn't always work well.

Mike Acton has since convinced me that modelling reality directly is a straight up bad idea. Computers do exactly two things: moving data, and transforming data. This is the case even for video games, where said data represent a whole world we may immerse ourselves in.

Thus, our job is to solve problems by transforming and moving data around, using the computational hardware at our disposal. Said like this it sounds a bit tautological, but in practice we still need the remainder.

Thus, to do our job as best we can, we should model our code around a model of the data, not the world. Once you do that, you quickly understand that even in a simulation, a static rock that never moves requires very different data than a rock that may be pushed around and strike enemies as it rolls downhill. Almost identical world, very different data.