4 ms·

It's funny you mention that, because Design of Everyday Things has a whole part about how people abstracting away the implementation leads to people having extr

by rtpg 3y ago

It's funny you mention that, because Design of Everyday Things has a whole part about how people abstracting away the implementation leads to people having extremely wrong ideas about how things work. I think abstraction is good in theory, but at the end of the day the implementation is what is happening. The classic thing of people relying on undocumented behavior, etc etc. What good is a conceptual representation that doesn't actually align with what happens? It's not like the gas pedal being pressed down is actually what makes a car accelerate, after all! Whenever you're dealing with something _not_ working as expected, those who know the implementation are going to be in a much more comfortable position in general IMO.

strogonoff 3y ago
Not understanding how things work can result in very suboptimal decisions, and throttle control is a good example. Even in a good old ICE car the throttle is not as straightforward as “more ‘gas’ equals more acceleration” (depending on many factors, such as road surface conditions, it can also make you go slower or stop completely). An airplane would take it to a whole new level. What throttle does is dependent on fuel mixture, air density at your altitude, the configuration of controls—in fact, it’s probably much easier to enumerate the limited scenarios in which throttle actually makes you go faster as opposed to straight up crash. There can be made an argument that smart systems could/should, with their layers of abstraction, maintain an illusion of ‘gas’ = acceleration, and that human should not have to know anything else; but would you trust your life to such an arrangement? There can be an argument that stakes are high in case of air travel, and low in case of VCS; but that falls apart if you consider source code managed in a VCS can indeed power a life-critical system, and if not knowing well enough how the VCS works can lead to development overhead and eventually bugs in that system, then human cost is real.
- p-e-w 3y ago
  The purpose of the VCS is to abstract away how its concepts are implemented. It should be possible to replace the standard Git implementation with any other that provides the same external interface without the user being affected, or even noticing it. If that isn't possible, the problem lies with Git, not with users "not understanding" it.
  - krupan 3y ago
    That's going a bit far. Git is heavily optimized for speed. If the implementation changed the UI could possibly stay the same but users would notice. Now, aside from that I think I generally agree with what you are saying. Git's UI, especially the way things are named, does feel very much tied to the implementation in ways that are a problem.
p-e-w 3y ago
> It's funny you mention that, because Design of Everyday Things has a whole part about how people abstracting away the implementation leads to people having extremely wrong ideas about how things work. Which, funnily enough, isn't a problem at all, unless the abstraction is leaky, or the purpose of the thing itself is poorly explained. The abstraction is "the way things work". If not, something is fundamentally wrong with the design.
- strogonoff 3y ago
  Every abstraction is leaky.
  - p-e-w 3y ago
    Not true in practice. Billions of websites work just fine when viewed on wildly different platform stacks, without developers or users ever having to care about differences in CPU architecture or kernel design.
    - strogonoff 3y ago
      That’s interface compatibility, not abstraction. For your example, you can just as well say that billions of cars work well on wildly different types of roads. Abstraction as in the throttle example is more like ORM vs. SQL (we all know someone who ran into issues with the former in a non-trivial project). You simplify the idea of X to Y, which works in Z% but breaks down otherwise.
  - kelnos 3y ago
    Sure, but the amount of leakiness varies a lot. And in practice, most of the time we just don't need to care. Of course the canonical, annoying examples of the leaky abstractions involve software stacks, where we end up writing a bunch of code, and find that things work great until weird edge cases happen, and then we get upset and have to dig through the abstractions to figure out what's going on. But the leaks in a lot of real-world abstractions just don't matter. Like the accelerator pedal in a car. That one does leak a bit in some places: for example, pressing the pedal isn't linear. On a (usually ICE) car with a geared transmission, pressing the pedal hard when in gear one gives you different results than when you press it hard when in gear six. But then you switch to an EV and the response is different. Or even switch to a different ICE car with a different transmission, and the response is different. But ultimately that doesn't really matter; the person driving gets used to it in very short order. The leaks in that abstraction just don't matter all that much.
Exoristos 3y ago
I have to say this is the first time I've heard accelerating by gas pedal described as undocumented behavior. > It's not like the gas pedal being pressed down is actually what makes a car accelerate In proximity to the driver it certainly is the cause.
fauigerzigerk 3y ago
>I think abstraction is good in theory, but at the end of the day the implementation is what is happening. Abstraction is absolutely necessary in practice. It's the language we use to tell a system what we want it to achieve. It's the only way for us to know what the system can do without starting a science project. It's the only way for the implementer to know what to implement. And it's the only way to check whether a system actually does what it's supposed to do. Of course, knowing how a system actually works is always better than not knowing it. Every abstraction is leaky as so many side-channel attacks clearly demonstrate. But that doesn't mean the abstraction is some theoretical pie in the sky that we can live without.
kelnos 3y ago
Is it actually a problem that people have the wrong ideas about how things work? Sure, if they need to actually know how something works (because, say, they want to dig in and modify the system itself), then of course they need to understand what happens below the abstraction. But if my goal is "drive a car", then it may not be helpful to know anything about that pedal beyond "car starts moving when I press the accelerator pedal". Because the nice thing is that I don't need to know about fuel injection or whatever happens when I press the accelerator on an ICE car. And the really nice thing is that if I switch from an ICE car to an EV, the basic usage is the same, and it doesn't matter that something completely, entirely different happens when I press that same pedal on those two different cars. (Ok, well, now we have one-pedal mode on some EVs, but... otherwise...)
- whilenot-dev 3y ago
  > Is it actually a problem that people have the wrong ideas about how things work? It can become a problem for when someone wants to make the switch from the consuming side to the producing side of things, or even just be part of a team that wants to do that. Every person first needs to be able to identify ones own faulty concept as misconception, and any decision made during this process involves a lot of risk.
- MrJohz 3y ago
  The problem with models is that once you've come up with a mental model, you will make assumptions about what happens when you do certain actions based on that model. And even if your model is very good, there will pretty much always be cases where your mental model differs from real life. For example, with the car analogy, you could have a very simple model that says that the accelerator pedal makes the car go faster - the harder you press the pedal, the faster the car goes. This model will break down, however, when you start driving in rough, wet, or snowy conditions. For those conditions, you need a more complex model that can take into account things like torque and grip. (I think: this analogy is taking me to the limit of my car knowing!) I worked on a project involving a device that could be configured. The backend developer's mental model was that the device was always in a configured state, and that you could then save the current configuration as a kind of preset, or replace the current configuration from an existing preset, or just change the configuration on the fly. The users, however, had a mental model more like files: they would load a configuration, make changes to that configuration, and then select a different configuration, expecting the previous configuration to be updated. In the end, these two mental models proved to be too incongruous, and we needed to switch the backend to use a different system internally that better matched user expectations. (Another option would be to build a UI that made the backend model more clearly.) In the case of git, the problem to me is that both mental models (diff-based and snapshot-based) are true and shown in different places. If you rely entirely on the diff-based model, you can use git very well, but you'll get weird errors when you start cherry-picking commits. If you rely entirely on the snapshot-based model, you'll be fine up until you want to rebase something, and then git will feel like dark magic. Both of these models can represent a lot of git operations, but if you take them too far, both will allow you to make a number of assumptions that aren't true. (I think there's also a nice analogy to physics as well here: Newtonian physics is a really good model of the way the universe works, it allows you to do a lot of very precise things with maths. But if you try and build a GPS system using only Newtonian physics, you'll find that your model doesn't match up to reality any more.)
someone7x 3y ago
Have you read the later book Living with Complexity? It is pretty much this topic; how to reconcile complexity and confusion. He talks a lot about reaching designs of irreducible complexity as a way to mitigate confusion. For what it’s worth, I’d say that Git is pretty far from irreduciby complex and thus has preventable confusion baked into it.
myaccountonhn 3y ago
See: LLMs and intelligence

by rtpg 3y ago

strogonoff 3y ago

Not understanding how things work can result in very suboptimal decisions, and throttle control is a good example. Even in a good old ICE car the throttle is not as straightforward as “more ‘gas’ equals more acceleration” (depending on many factors, such as road surface conditions, it can also make you go slower or stop completely). An airplane would take it to a whole new level. What throttle does is dependent on fuel mixture, air density at your altitude, the configuration of controls—in fact, it’s probably much easier to enumerate the limited scenarios in which throttle actually makes you go faster as opposed to straight up crash. There can be made an argument that smart systems could/should, with their layers of abstraction, maintain an illusion of ‘gas’ = acceleration, and that human should not have to know anything else; but would you trust your life to such an arrangement? There can be an argument that stakes are high in case of air travel, and low in case of VCS; but that falls apart if you consider source code managed in a VCS can indeed power a life-critical system, and if not knowing well enough how the VCS works can lead to development overhead and eventually bugs in that system, then human cost is real.

p-e-w 3y ago
The purpose of the VCS is to abstract away how its concepts are implemented. It should be possible to replace the standard Git implementation with any other that provides the same external interface without the user being affected, or even noticing it. If that isn't possible, the problem lies with Git, not with users "not understanding" it.
- krupan 3y ago
  That's going a bit far. Git is heavily optimized for speed. If the implementation changed the UI could possibly stay the same but users would notice. Now, aside from that I think I generally agree with what you are saying. Git's UI, especially the way things are named, does feel very much tied to the implementation in ways that are a problem.

p-e-w 3y ago

> It's funny you mention that, because Design of Everyday Things has a whole part about how people abstracting away the implementation leads to people having extremely wrong ideas about how things work. Which, funnily enough, isn't a problem at all, unless the abstraction is leaky, or the purpose of the thing itself is poorly explained. The abstraction is "the way things work". If not, something is fundamentally wrong with the design.

strogonoff 3y ago
Every abstraction is leaky.
- p-e-w 3y ago
  Not true in practice. Billions of websites work just fine when viewed on wildly different platform stacks, without developers or users ever having to care about differences in CPU architecture or kernel design.
  - strogonoff 3y ago
    That’s interface compatibility, not abstraction. For your example, you can just as well say that billions of cars work well on wildly different types of roads. Abstraction as in the throttle example is more like ORM vs. SQL (we all know someone who ran into issues with the former in a non-trivial project). You simplify the idea of X to Y, which works in Z% but breaks down otherwise.
- kelnos 3y ago
  Sure, but the amount of leakiness varies a lot. And in practice, most of the time we just don't need to care. Of course the canonical, annoying examples of the leaky abstractions involve software stacks, where we end up writing a bunch of code, and find that things work great until weird edge cases happen, and then we get upset and have to dig through the abstractions to figure out what's going on. But the leaks in a lot of real-world abstractions just don't matter. Like the accelerator pedal in a car. That one does leak a bit in some places: for example, pressing the pedal isn't linear. On a (usually ICE) car with a geared transmission, pressing the pedal hard when in gear one gives you different results than when you press it hard when in gear six. But then you switch to an EV and the response is different. Or even switch to a different ICE car with a different transmission, and the response is different. But ultimately that doesn't really matter; the person driving gets used to it in very short order. The leaks in that abstraction just don't matter all that much.

Exoristos 3y ago

I have to say this is the first time I've heard accelerating by gas pedal described as undocumented behavior. > It's not like the gas pedal being pressed down is actually what makes a car accelerate In proximity to the driver it certainly is the cause.

fauigerzigerk 3y ago

>I think abstraction is good in theory, but at the end of the day the implementation is what is happening. Abstraction is absolutely necessary in practice. It's the language we use to tell a system what we want it to achieve. It's the only way for us to know what the system can do without starting a science project. It's the only way for the implementer to know what to implement. And it's the only way to check whether a system actually does what it's supposed to do. Of course, knowing how a system actually works is always better than not knowing it. Every abstraction is leaky as so many side-channel attacks clearly demonstrate. But that doesn't mean the abstraction is some theoretical pie in the sky that we can live without.

kelnos 3y ago

Is it actually a problem that people have the wrong ideas about how things work? Sure, if they need to actually know how something works (because, say, they want to dig in and modify the system itself), then of course they need to understand what happens below the abstraction. But if my goal is "drive a car", then it may not be helpful to know anything about that pedal beyond "car starts moving when I press the accelerator pedal". Because the nice thing is that I don't need to know about fuel injection or whatever happens when I press the accelerator on an ICE car. And the really nice thing is that if I switch from an ICE car to an EV, the basic usage is the same, and it doesn't matter that something completely, entirely different happens when I press that same pedal on those two different cars. (Ok, well, now we have one-pedal mode on some EVs, but... otherwise...)

whilenot-dev 3y ago
> Is it actually a problem that people have the wrong ideas about how things work? It can become a problem for when someone wants to make the switch from the consuming side to the producing side of things, or even just be part of a team that wants to do that. Every person first needs to be able to identify ones own faulty concept as misconception, and any decision made during this process involves a lot of risk.
MrJohz 3y ago
The problem with models is that once you've come up with a mental model, you will make assumptions about what happens when you do certain actions based on that model. And even if your model is very good, there will pretty much always be cases where your mental model differs from real life. For example, with the car analogy, you could have a very simple model that says that the accelerator pedal makes the car go faster - the harder you press the pedal, the faster the car goes. This model will break down, however, when you start driving in rough, wet, or snowy conditions. For those conditions, you need a more complex model that can take into account things like torque and grip. (I think: this analogy is taking me to the limit of my car knowing!) I worked on a project involving a device that could be configured. The backend developer's mental model was that the device was always in a configured state, and that you could then save the current configuration as a kind of preset, or replace the current configuration from an existing preset, or just change the configuration on the fly. The users, however, had a mental model more like files: they would load a configuration, make changes to that configuration, and then select a different configuration, expecting the previous configuration to be updated. In the end, these two mental models proved to be too incongruous, and we needed to switch the backend to use a different system internally that better matched user expectations. (Another option would be to build a UI that made the backend model more clearly.) In the case of git, the problem to me is that both mental models (diff-based and snapshot-based) are true and shown in different places. If you rely entirely on the diff-based model, you can use git very well, but you'll get weird errors when you start cherry-picking commits. If you rely entirely on the snapshot-based model, you'll be fine up until you want to rebase something, and then git will feel like dark magic. Both of these models can represent a lot of git operations, but if you take them too far, both will allow you to make a number of assumptions that aren't true. (I think there's also a nice analogy to physics as well here: Newtonian physics is a really good model of the way the universe works, it allows you to do a lot of very precise things with maths. But if you try and build a GPS system using only Newtonian physics, you'll find that your model doesn't match up to reality any more.)

someone7x 3y ago

Have you read the later book Living with Complexity? It is pretty much this topic; how to reconcile complexity and confusion. He talks a lot about reaching designs of irreducible complexity as a way to mitigate confusion. For what it’s worth, I’d say that Git is pretty far from irreduciby complex and thus has preventable confusion baked into it.

myaccountonhn 3y ago

See: LLMs and intelligence