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.
>Could we do more to make programming an accessible activity to the 99% of people who don’t program, by putting greater emphasis on intuitive physical analogs?
I think this would have to be done carefully.
Being able to articulate your thoughts and compute without resorting to physical analogies can greatly reduce the processing load on your brain. This is partly due to the fact that analogies always come with a baggage of extra features that are unrelated to the concept you actually care about.
Perhaps a good way to overcome this would be to carefully pick a set of analogies for a concept,then identify what about these multiple analogies helps you understand it. It would also help you abstract away the additional semantic load that comes with the chosen physical analogies.
I am however, a strong believer in the power of metaphors to democratize complex craft.
Music composition per example, can be made more intuitive and accessible by thinking of sounds events in terms of their physical analogues. In the case of sounds however, the extra semantic fat may very well be marbling on wagyu beef.
In fact, it would help us think of musical composition in a more... compositional way, i.e. combination of parts with different semantic properties that when combined following certain rules, generate an expression with a particular meaning.
I don't know that I agree on the container and person approach for everyone but I appreciate you writing an article on this topic.
I think about this a lot and I do tend to think that better analogies and metaphors can help people get into programming.
Two areas I've mined for analogies are cooking and legal work.
There is a book called developer hegemony that I have not read yet. As I understand it makes the comparison between software developent and being a lawyer. Seems like there might be some good ones in there to use.
The other one is cooking. When I talk to people about writing code who have never done it before one of the concerns they often have is that they could never write it exactly "right" that it's too complicated in that way. I like the analogy of cooking here to try to explain that while there is the 5 star chef version, there is also making a grilled cheese at home. I think you might be able to take that analogy pretty far. Comparing meals to software and so on. Talk about ingredients as libraries, that sort of thing ("you can start with flour or there is some delicious puff pastry in the pip3 cabinet")
Hard disagree that most of these are metaphors in actual use. They’re more like mnemonics, arbitrary names for highly abstract concepts that are only incidentally borrowed from ordinary languages.
For example, I never think of a physical dictionary when using the data structure. Much less a heap or a tree (we even draw those with the root at the top!). And the stuff in the article about database queries being “supplications” is just ridiculous. It’s again an abstract idea. No idea of a the social relationship between humans ever enters the picture in any way, metaphoric or otherwise.
What’s hard about programming isn’t the names, it’s learning the concepts. At least in my opinion.
And yet... in a mysterious and unfathomable coincidence, one of the biggest corporate DB companies is literally called Oracle.
That's the point about Lakoff's metaphors. We use them without being aware of them. And yes - there's a social and political element as well as a (pseudo)tangible one.
Although in this case I'd suggest they're more like analogies. If you had never seen a physical wall of storage boxes - in photos or the movies is fine, you don't need a direct personal experience - wouldn't it be harder to imagine what a key/value store is?
You may think you'd just know. But would you?
Most people find programming hard because they don't have these metaphors to (metaphorical) hand. You need a certain mindset which understands representations, relationships, and transformations in a certain kind of way.
People who have this find the basics "obvious" and can usually be trained to work their way up to more complex abstractions.
Make sure to follow up "Metaphors We Live By" with a read of Lakoff's "Women, Fire and Dangerous Things", which explains how meaning is constructed by ultimately relating sounds to body experiences, a must-read for the interested student of linguistics (amateur or professional).
The data realm has a fun set of metaphors. For example, DATA IS A PHYSICAL MATERIAL. It can be CLEANED, MINED, EXTRACTED, FILTERED, POLISHED, PIPED, etc.
I don't buy Lakoff's idea that meaning is fundamentally metaphorical. For one thing, it fails to account for our ability to judge the aptness of a given metaphor. There's a book, Understanding Figurative Language, that makes a critique along these lines.
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