Neat, I skimmed through "metaphors we live by" a few weeks ago and can't stop applying it everywhere. I recently wrote a post that's kind of on "GOOD CODE IS CLEAN" [1].
I can't recall how dependent I was on physical metaphors when I was first learning to code. I do, however, remember some times that I tried to learn concepts and a spatial metaphor set me back significantly. Like "railway-oriented" for async error handling (which just over complicated things), or "monad is a burrito" (which, was fine for when you already understood the concept, but useless before). I guess my point is that it's quite difficult to know if a metaphor is a good learning tool if you already know the concept.
Great feedback re the risks of physical metaphors! I'd agree a bad one does more harm than good. Lakoff points out that our linguistic conceptions typically compose-- so you can talk about both IDEAS as BUILDINGS and as CONTAINERS because the former is a special case of the latter-- and we lose that quickly when mapping to programming. I'm not sure if that's inherent in how abstract these things are or if it just hasn't been attempted on a deep enough level. (Do other control structures fit into the railway paradigm? Is it generative?)
Enjoyed your post, lots to unpack in the 'cleanliness' analogy, will think on it.
I can't recall how dependent I was on physical metaphors when I was first learning to code. I do, however, remember some times that I tried to learn concepts and a spatial metaphor set me back significantly. Like "railway-oriented" for async error handling (which just over complicated things), or "monad is a burrito" (which, was fine for when you already understood the concept, but useless before). I guess my point is that it's quite difficult to know if a metaphor is a good learning tool if you already know the concept.
[1] https://ravik.substack.com/p/an-anthropology-of-clean-code