[ithkuil]

not literally LEGOs, but many industries are based on repeated application of basic building blocks. The simplest and most ancient example are ... bricks: you build walls by composing objects of a few standardized sizes. This sounds obvious but it's not how things were always made; if you build a wall with stones, you have to invest more time into fitting them together neatly (and often you have to use a hammer to break larger stones apart). Construction has other examples of composition of prefabricated modules.

Another example, a lot of electronics was (and still is) implemented by combining discrete components with well known behaviours (things like https://en.wikipedia.org/wiki/7400-series_integrated_circuit...). At many levels in electronics you have abstractions upon abstractions (transistors -> logical gates -> multiplexers -> ALUs -> CPUs; communication busses, etc etc)

[cgrealy]

You can build a house with bricks. But you also need adhesive. And past a certain (very low) complexity, you probably use wooden framing, cut to size. And a different material for the roof, and glass for the windows and some kind of insulation, plastics for piping, and so on and so on and so on. And that’s not even getting started on more complex buildings.

As for electronics, yep, you start with discrete components, but as you said yourself, you quickly end up with specifically designed components for efficiency.

[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!