[ithkuil]

I don't think that software reuse the goal is to be zero-glue; perhaps that part of the LEGO analogy (the lack of glue) distracts a bit.

What often happens with software development is that despite all the abstractions that get built while building one piece of software, it often turns out those abstractions can't be just pulled out and reused in another context because often those abstractions are too leaky.

I think the "original sin" stems from how "cheap" it is to write a line of code, and another one, and another one. It's not that good abstractions are never being built during software development; but when they do they usually take a long time to mature and have to be sought purposefully (and they cost way much more to engineer).

What sets software development apart from other forms of engineering is that it's often "ok" to build a house with mud and sticks that will collapse on the first strong gust of wind because ... "because it's just a POC", "let's see if we really have customers before doing it right", "making this too well has an opportunity cost of not doing something else", etc etc

[cgrealy]

The point of Lego is not the zero glue, the point is that all components share a common interface.

>>What often happens with software development is that despite all the abstractions that get built while building one piece of software, it often turns out those abstractions can't be just pulled out and reused in another context because often those abstractions are too leaky.

My question is whether a non-leaky abstraction is even valuable.

Look at a real world example of non-trivial component reuse: a vehicle engine.

It has a single purpose: convert chemical energy to kinetic energy, and they're really expensive to develop.

But you can't just drop a v6 into a Tesla.

[ithkuil]

yet it's clearly useful to have the concept of "the engine" even if you cannot drop it in any vehicle.

E.g. it's a clear boundary between teams that collaborate on the "car" system, it's something some engineers specialize in that is quite different from "suspension system" (and such knowledge can be carried across engine design instances).

But you're right, when we're talking about LEGO-style composability, as you said, it's about having pieces that fit together and can be rearranged in many ways, and the real world is far messier and rarely you have universal composability; there are instances of "bounded" composability; e.g. the tyres for my car likely fit many other similar vehicles, but not all.

[cgrealy]

>> yet it's clearly useful to have the concept of "the engine" even if you cannot drop it in any vehicle.

Absolutely! I'm not arguing against modularity at all. I think the concept of discrete subsystems interacting is pretty much universal (organs, components, rooms, streets).

>> there are instances of "bounded" composability; e.g. the tyres for my car likely fit many other similar vehicles, but not all.

Again, completely agree.

What I'm arguing against is uniformity of interface.

You wouldn't connect a tyre to a wheel the same way you would mount an engine to a chassis.

[ithkuil]

> What I'm arguing against is uniformity of interface.

> You wouldn't connect a tyre to a wheel the same way you would mount an engine to a chassis.

Yes, you're right, LEGO is extremely uniform, and no real system is _that_ uniform.

And even a uniform interface doesn't mean any combination makes sense.

Attaching a LEGO brick with wheels on the roof of a LEGO car is not different than soldering an axle on the roof of a car: technically possible but utterly useless.

Actually, soldering an axle on the roof of a car is composing uniform interfaces: atoms in chemical bonds form a finite set of building blocks too!