4 ms·

Yes! It just seems so strange not to care about how things actually are in software. Is it a way of coping with the fact that so much software is so deeply laye

Yes! It just seems so strange not to care about how things actually are in software. Is it a way of coping with the fact that so much software is so deeply layered and complex now? Maybe I’m misremembering, but I feel like I didn’t see this usage of “mental model” much until fairly recently. The first I recall being surprised at was a discussion of a “mental model of Javascript” -- why would you need a mental model of something with a very detailed spec and multiple compatible implementations to study? If you want to understand how some aspect works, just look up how it actually does work.

Dylan16807 6y ago
Unless you open up the spec every single time you make a prediction, you're using a mental model. And the spec is probably not arranged for easy use.
- iudqnolq 6y ago
  It's necessary to approximate, but if someone tells you your approximation is wrong it makes no sense to say it's right because you prefer it that way. If your mental model is that floats are real numbers and someone tells you they aren't, you don't go "I philosophically prefer to think they're reals, so you're wrong". You either update your mental model or decide you'd rather be a bit wrong than learn something (you perceive as) tedious.
  - Dylan16807 6y ago
    Sure, you usually don't want your mental model to be wrong on purpose. But that's different from not having one. And sometimes a slightly wrong model has other benefits that will cause you to make less mistakes, so it's still a good tool.
tsimionescu 6y ago
Well, sometimes the API of a piece of software presents one model, while the implementation actually uses a different model underneath for various reasons. In particular in Git, some commands expose the commits-as-diffs model (cherry-pick, rebase) while others present the commits-as-snapshots model (checkout). However, if you were to look at various layers of git code, the model is either commits-as-snapshots, or neither (compressed storage). You could also theoretically change the entire implementation of git to store commits as diffs, and offer the exact same API as it does today (probably with differences in the way conflicts are resolved, and definitely with differences in performance).

Dylan16807 6y ago

Unless you open up the spec every single time you make a prediction, you're using a mental model. And the spec is probably not arranged for easy use.

iudqnolq 6y ago
It's necessary to approximate, but if someone tells you your approximation is wrong it makes no sense to say it's right because you prefer it that way. If your mental model is that floats are real numbers and someone tells you they aren't, you don't go "I philosophically prefer to think they're reals, so you're wrong". You either update your mental model or decide you'd rather be a bit wrong than learn something (you perceive as) tedious.
- Dylan16807 6y ago
  Sure, you usually don't want your mental model to be wrong on purpose. But that's different from not having one. And sometimes a slightly wrong model has other benefits that will cause you to make less mistakes, so it's still a good tool.

tsimionescu 6y ago

Well, sometimes the API of a piece of software presents one model, while the implementation actually uses a different model underneath for various reasons. In particular in Git, some commands expose the commits-as-diffs model (cherry-pick, rebase) while others present the commits-as-snapshots model (checkout). However, if you were to look at various layers of git code, the model is either commits-as-snapshots, or neither (compressed storage). You could also theoretically change the entire implementation of git to store commits as diffs, and offer the exact same API as it does today (probably with differences in the way conflicts are resolved, and definitely with differences in performance).