Follow

@emsenn

Hmm, I'm a bit concerned that I've been inarticulate. There is a concept of "simple" that means something like "easy to use", but that's *not* the meaning I have in mind.

I'm talking about something more like "few moving parts/reliable/easy to maintain". And, even at that level, the microwave dinner might be "simple". Or maybe a better example is the dried food I use when backpacking—all it needs is the pouch, water, a pan, and a heat source—very few moving parts, and very simple.

@codesections

Helpful but I stand by it - Windows has very few moving parts if you accept their abstraction (because all the moving parts are behind the scenes/in their factory, like the microwave dinner)

If you're internalizing externalities - looking at the whooole ecosystem of abstractions and work involved in getting to the bread/meal...

@emsenn @codesections The point of the "moving parts" analogy is that you aren't accepting an abstraction. To count the moving parts of a machine, you have to take it all the way apart.

Windows-paradigm apps aren't composable. Composable things can be simpler (have fewer moving parts) than equivalently powerful non-composable things.

@kragen @emsenn @codesections
I think the point of the 'moving parts' analogy is the repair metaphor: it only matters that parts are intended to move when they aren't moving correctly. In other words, it's a matter of chunking. In this way @emmsenn@tenforward.social's model is right, so long as there aren't abstraction leaks. (I find Windows really annoying because when I run into a problem, I want to *fix* it myself.)

@enkiv2 @kragen @emsenn @codesections
We can sort of arbitrarily break stuff down until our moving parts are individual electrons, but god help us if we encounter a problem that forces us to do so. Alternately, we can treat as a black box anything for which treating it as a black box reliably saves us complexity & reliably does not misrepresent behavior. In other words: the definition of a module is that it's rock solid so you never need to look inside.

@enkiv2 @kragen @emsenn @codesections
This sort of explains the popularity of systems with technical vs nontechnical users. It's not that technical users love arcane shit per-se, but that arcane shit isn't so arcane to them. For Windows' intended audience, if the computer breaks you throw it in the trash & get a new one. A programmer can understand how to fix shit if they're allowed to look inside, so naturally they're annoyed that they're not allowed to.

@enkiv2 @emsenn @codesections counting moving parts is not only useful for estimating the cost of repair, but also for estimating the number of wear surfaces that can separately wear out or go out of tolerance, and for estimating how hard it would be to make one of your own. It's not a matter of chunking; assemblies of moving parts are not moving parts.

@kragen @enkiv2 @emsenn @codesections
I don't think it's a matter of cost of repair. I think it's a matter of cognitive cost of imagining possible repairs. (This applies doubly or triply to when we use it as a metaphor.) Again: we don't treat every electron as a moving part.

@enkiv2 @emsenn @codesections Electrons don't wear, can't be out of tolerance, don't have to be separately machined, don't need an access path for replacement, and don't have to be individually assembled. That's why we don't treat them as moving parts: they don't have many of the characteristics of moving parts.

Sign in to participate in the conversation
Fosstodon

Fosstodon is a Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.