Live data from Hacker News

Holding a Program in One's Head (2007)

paulgraham.com

11–20 of 114 posts

Re: Holding a Program in One's Head (2007)

#11

> 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…

There's some idiom that says something like "you don't understand something if you can't explain it." I think this is the real point of code review. To make a case for why your code is valuable. If it's just a blob of 1000 lines of "refactor" or "adding feature." It means nothing. A good commit has some kind of abstract tailored to what work was done.

Then a review becomes something like "the claim was made this function does this, does it look like the function does what it says it does?" If you can understand it in context, then you've added trust and knowledge of how it works.

However it seems to often be the case a review turns into "I like this word better than that word" so back to the explaining it point, it becomes a bit of a self review with the hope it might be helpful to somebody else in the future.

Re: Holding a Program in One's Head (2007)

#12
"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.

Re: Holding a Program in One's Head (2007)

#13

> […] 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…

Said another way: push interface up and implementation down.

Re: Holding a Program in One's Head (2007)

#14

> 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…

[deleted]

Re: Holding a Program in One's Head (2007)

#15

I once watched a presentation by Dan North where he said that a microservice should never be bigger than your head. What he meant was that all the code for the microservice should fit on your screen and you should be able to put your head against the screen and it should cover the code. Yes, this was in the microservices-heyday.

A quote originally (AFAIK) from the wonderful book 'Practical Common Lisp'. https://gigamonkeys.com/book/

This is probably a common; lisp/scheme type of thought. Dan Friedman also said something about how he only likes code that he can hold in his head to think about in the shower. I forgot the source, but it's in one of the talks. I think Sussman has also said something similar.

Re: Holding a Program in One's Head (2007)

#16

> […] 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…

This seems to be one of the core lessons behind John Ousterhout's _A Philosophy of Software Design_

https://www.goodreads.com/book/show/39996759-a-philosophy-of...

and I find that the mechanism of "Literate Programming":

https://literateprogramming.com/

is a useful one for doing this since it allows one to write about both how the low level details are implements in a function, _and_ how the written function is used in a way which allows the twain to support each other.

Re: Holding a Program in One's Head (2007)

#17
post #9

> 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…

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 read assumptions and see branches taken and what’s wrong as if it was written in plain text.

When I see klocs without a single log statement, to me it’s readonly and not worth touching. If you’re stuck with a bug, log everything and you’ll see it right there.

Re: Holding a Program in One's Head (2007)

#18
Take 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.

Re: Holding a Program in One's Head (2007)

#19
post #12

"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.

Succinct languages don't force you to be succinct. They only allow you to be succinct where it helps.

(I'm sure there are exceptions, but in the set of languages that enable succinctness, the subset that force succinctness is surely small.)

Re: Holding a Program in One's Head (2007)

#20
post #12

"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 think this is addressed in the link under that section

https://paulgraham.com/power.html

> I think that the main reason we take the trouble to develop high-level languages is to get leverage, so that we can say (and more importantly, think) in 10 lines of a high-level language what would require 1000 lines of machine language.

...

> 5. Write rereadable code. All programmers know it's good to write readable code. [...] If you're writing for other people, you may not want to make code too dense. Some parts of a program may be easiest to read if you spread things out [...] Whereas if you're writing code to make it easy to reload into your head, it may be best to go for brevity.

Post reply on HN