This is a useful analogy and very salient to me at this moment. I want to point at some related things:
1. The idea that all code inside a function should be written at one level of abstraction lower than its name. This would ensure that every function contains a set of boxes of approximately the same “size”, which build up the bigger box of the container function in a way that makes sense. (How do molecules add up to this brick? How do bricks add up to this wall?) 2. More generally, if all of the names in your code are well-chosen, it will read somewhat like prose. I think that this would contribute a lot towards ease of reading and will generate fewer distractions, especially for people less familiar with the codebase or language.
The lesson I personally got out of this post is that we should be careful in naming concept handles for this same reason. Good concept handles will point at the underlying idea in a way that gives you a sense of what it means even without knowing the term. This lets it feel less like jargon (as “Hansonian markets” would have done, nice example) and makes it easier for other people to take part in a conversation/read up on a topic/etc without needing to step away to open the boxes every time. (Most existing terminology is already so established that it would probably be more confusing to change it now. Which is very sad. It could streamline so many discussions, especially in interdisciplinary research, if things were named in a way that directs you to the right boxes to open.)
The idea that all code inside a function should be written at one level of abstraction lower than its name. This would ensure that every function contains a set of boxes of approximately the same “size”, which build up the bigger box of the container function in a way that makes sense. (How do molecules add up to this brick? How do bricks add up to this wall?)
That’s a great point with an even more awesome example! Thanks! I’m gonna remember that example.
The lesson I personally got out of this post is that we should be careful in naming concept handles for this same reason.
Yeah. I really wanted to talk more about everyday life and make the post less about code. I just wasn’t able to make it work.
This is a useful analogy and very salient to me at this moment. I want to point at some related things:
1. The idea that all code inside a function should be written at one level of abstraction lower than its name. This would ensure that every function contains a set of boxes of approximately the same “size”, which build up the bigger box of the container function in a way that makes sense. (How do molecules add up to this brick? How do bricks add up to this wall?)
2. More generally, if all of the names in your code are well-chosen, it will read somewhat like prose. I think that this would contribute a lot towards ease of reading and will generate fewer distractions, especially for people less familiar with the codebase or language.
The lesson I personally got out of this post is that we should be careful in naming concept handles for this same reason. Good concept handles will point at the underlying idea in a way that gives you a sense of what it means even without knowing the term. This lets it feel less like jargon (as “Hansonian markets” would have done, nice example) and makes it easier for other people to take part in a conversation/read up on a topic/etc without needing to step away to open the boxes every time.
(Most existing terminology is already so established that it would probably be more confusing to change it now. Which is very sad. It could streamline so many discussions, especially in interdisciplinary research, if things were named in a way that directs you to the right boxes to open.)
That’s a great point with an even more awesome example! Thanks! I’m gonna remember that example.
Yeah. I really wanted to talk more about everyday life and make the post less about code. I just wasn’t able to make it work.