4 ms·

> Why have so many people written long thoughtful explanations about how the author is wrong to suggest snapshots are a better mental model, and that you think

> Why have so many people written long thoughtful explanations about how the author is wrong to suggest snapshots are a better mental model, and that you think all abstractions are leaky, but you find diffs a better mental model? Probably because, to take their words at face value, they find diffs a better mental model? I think impugning "people [...] are so deeply attached to their understanding that they didn't hear most of what the article said" is a real bad faith reading, especially when you even acknowledge that central to people's arguments is "all mental models are leaky". This article may be technically correct about the way git internals are structured, but it makes cherry-pick and rebase more mentally complex for users to understand (you first have to go from commit => patch), not less. Saying "Commits are collections of files + a parent commit, but you can diff it to generate a patch" and saying "Commits are a patch + a parent commit, and you can apply it to generate a collection of files" are isomorphic mental models—the fact that #1 is "correct" (for some value of correct that doesn't include the actual files stored on disk) is really besides the point.

iudqnolq 6y ago
My point is that people criticizing TFA's proposed mental model are missing the fact that TFA doesn't propose a mental model, it explains how things work. Both have value, but they're distinct.
- nightpool 6y ago
  I disagree. TFA is explaining the mental model Git uses to structure their codebase. If you're writing code for Git, this is obviously very useful to understand, but if you're just using it, this is only one of several mental models available to you. In this case, I think it's right to say that the distinction the author is attempting to draw is immaterial to those not working on the Git codebase.
  - iudqnolq 6y ago
    If your code is written in a certain way that's a model, not a mental model.
    - iainmerrick 6y ago
      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).

iudqnolq 6y ago

My point is that people criticizing TFA's proposed mental model are missing the fact that TFA doesn't propose a mental model, it explains how things work. Both have value, but they're distinct.

nightpool 6y ago
I disagree. TFA is explaining the mental model Git uses to structure their codebase. If you're writing code for Git, this is obviously very useful to understand, but if you're just using it, this is only one of several mental models available to you. In this case, I think it's right to say that the distinction the author is attempting to draw is immaterial to those not working on the Git codebase.
- iudqnolq 6y ago
  If your code is written in a certain way that's a model, not a mental model.
  - iainmerrick 6y ago
    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).