It's (mostly) not about the code. It's about the data structures and their relations.
Holding a Program in One's Head (2007)
31–40 of 114 posts
Re: Holding a Program in One's Head (2007)
#32> […] bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above I like to explain this as “hide the bad parts behind a good API”. Anything interesting is going to require “bad parts”, which just means the low-level, difficult work. From there, compose up and up until a high level orchestration is achieved. It works so much better than the bad pa…
I think that many, perhaps even most, engineers incorrectly believe that the main purpose of abstraction in code is simply DRY, as if the goal is to save keystrokes or something. In my view, the purpose of abstraction is to compress the concepts of your application into digestible and manueverable chunks, and DRY is just a heuristic for beginners to follow to help point to where appropriate abstraction boundaries may…
I think DRY should be supplemented by "Don't make me read it multiple times". Repeat yourself, by all means, if that makes it so that I don't get all twisted up jumping between so many files that I can't keep the main thread straight while I read your code.
Re: Holding a Program in One's Head (2007)
#33I call this program in one's head "suspended comprehension" as it has a degree of transience and fragility that requires effort to resume where you left off.
Re: Holding a Program in One's Head (2007)
#34Earlier quoted context omitted.
I often tell younger engineers that the human brain is the slowest, lowest-memory, and most error-prone runtime for a program. If they're stuck trying to figure out a bug, one of the most effective things they can do is validate their assumptions about what's happening, because there wouldn't be a bug if everything was happening exactly according to expectations.
That’s why I learned to log literally everything into stdout unless a process is time-sensitive and it’s deep production and it passed the mark where bugs and insights occur once a month+ and there’s zero chance someone asking me what exactly happenes with X at Y afternoon-ish last Friday. The obvious exception are recursive number-fiddling algos which would spam gigabytes of output due to big N. This way I can just…
For large systems the cost of maintaining all of those logs in a searchable system can be prohibitive.
Re: Holding a Program in One's Head (2007)
#35> […] bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above I like to explain this as “hide the bad parts behind a good API”. Anything interesting is going to require “bad parts”, which just means the low-level, difficult work. From there, compose up and up until a high level orchestration is achieved. It works so much better than the bad pa…
I think that many, perhaps even most, engineers incorrectly believe that the main purpose of abstraction in code is simply DRY, as if the goal is to save keystrokes or something. In my view, the purpose of abstraction is to compress the concepts of your application into digestible and manueverable chunks, and DRY is just a heuristic for beginners to follow to help point to where appropriate abstraction boundaries may…
Good API is for encapsulating and communicating ideas between other programmers or teams.
DRY is for improving communication with your future self.
Re: Holding a Program in One's Head (2007)
#36> You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. There is certainly some truth to this. On the other hand, it's possible to become blinded to defects in code you've written yourself. You see what you intended for the code to do rather than what it actually does. Reading someone else's code, it can be easier to see what's real…
The comparison with mathematics also makes sense here. It’s much easier to spot typos in other peoples’ work than your own for exactly that reason: when you read back what you wrote, you read back what you meant to write rather than what’s actually there.
Open any textbook (even a fourth edition of a famous one, written by an expert) and you’ll find countless typos. In fact, in a certain sense, the more expert you are the less suitable you are as a proof reader for such books.
Re: Holding a Program in One's Head (2007)
#37"Use succinct languages" is somewhat at odds with "Write rereadable code." There's a point beyond which making your code more succinct makes it more difficult for a human to parse. This can be somewhat mitigated by comments but I'd rather just read more readable code than more succinct code.
I completely disagree.
It's possible to write code so succinct that making it more verbose would make it more understandable.
But overly verbose code is far, far more common. And having a naturally succinct language does not stop you from keeping your code verbose. Just gives you more ways to make your code succinct that aren't possible in non-succinct languages.
(Not this is orthogonal to weaker or stronger compile time type systems. Type systems that catch more errors at compile time are very useful. But some strongly compile-time typed languages are still quite succinct.)
Re: Holding a Program in One's Head (2007)
#38> You can magnify the effect of a powerful language by using a style called bottom-up programming where you write programs in multiple layers, the lower ones acting as programming languages for those above. If you do this right, you only have to keep the topmost layer in your head.
And if you do it wrong (overengineering), you would need to learn not just one, but as many programming languages as there are layers...
Re: Holding a Program in One's Head (2007)
#39Take a look at the list of people who read the draft of this post. > Thanks to Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, and Stephen Wolfram for reading drafts of this.
People who are famous for running companies and not writing code.
Robert Morris, Peter Norvig and Stephen Wolfram didn't write code?
(I don't recognize some of the others.)
Re: Holding a Program in One's Head (2007)
#40> You can magnify the effect of a powerful language by using a style called bottom-up programming where you write programs in multiple layers, the lower ones acting as programming languages for those above. If you do this right, you only have to keep the topmost layer in your head. And if you do it wrong (overengineering), you would need to learn not just one, but as many programming languages as there are layers...
That's IMHO what OOP (as understood in Java world) tends to evolve to...