And how many accidents are there in Wisconsin in January with 8 inches of snow on the ground?
We don’t have to perfect automated driving; we just have to get it better than the average human… and that’s a pretty low bar.
And we don’t even have to automate driving everywhere. Who cares if we can’t automate it for 5%? Can we automate it for 95%? Hell, if we can automate it for 30-40% with a lower accident rate… that’s already a win.
And honestly, from a business perspective, most people really don't care about the skills ordinary people have.
Look at the wine industry for example. Top shelf wine is hand-picked, for exactly the reasons you outline, and some people are willing to pay top dollar for that end product.
But the vast majority of grapes are harvested by very simple machines, because scale and profit, and most people just want a $10 bottle of decent-ish wine.
We absolutely can automate cooking a fucking hamburger, and as soon as it's cheaper than the cheapest labour, McDonald's, Burger King, etc, WILL automate cooking a fucking hamburger.
Will it be as good as a "hand made" burger? Maybe.. maybe not?
Will the people paying a few bucks for a burger care? Nope.
This isn't an issue with "computer people"... this is an issue with economics.
>> 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.
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.
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.
I read every comment waiting to see if someone would point out the obvious.
This blog is 100% accurate, and nearly everyone took the wrong point away from it.
There is a very good reason we don’t build anything but the most trivial structures from Lego.
Composability and reusability are great, but not at the expense of suitability for purpose.
You could build a house or a car out of Lego, but it would be worse on almost every possible metric than a regular house (unless your primary use case for your house is to take it apart and reconfigure it easily).
The same goes for software. You could build everything from unix pipes, but that rarely happens past the most trivial scale.
In fact, the clue is in the article. Evolution is not very tolerant of inefficient systems; animals haven’t evolved hot swappable organs, they have a complex interconnected system because 99% of the time, it works better.
As always, the answer is highly dependant on a number of factors:
- How complex is X?
- What expertise do you have available for X?
- How critical is X?
But in general, if X is not part of your core business, only as a last resort.
99% of the time, even if there is a suboptimal library, as long as its actively maintainted, you're better off extending the functionality, than re-implementing.
And you also need to understand your timing requirements.
If all you care about is recording a date on an invoice, you really don’t need to worry about leap seconds or smearing or whatever.