Ask HN: Do You Program on Paper?

5 pointsmcmicah2y ago9 comments

I'm increasingly tiring of sitting in front of a computer and typing all day, and frequently wish that it was more convenient to work while walking or outside. I also find thinking with pen and paper to be much more pleasant. I've been thinking about figuring out a way to do my actual programming work on paper, and only transcribing at the last moment, but using most computer languages isn't really optimized for that usage. I've strongly considered using APL for it, since it's much more like a conventional math notation and pretty suitable for paper usage, but converting the result at the end isn't very easy unless I actually want APL- which honestly has a lot of disadvantages in this era. Has anyone considered this problem before or made any tooling to make it more viable?

9 comments

rzzzwilson2y ago

I often draw "boxes and arrows" in the high-level design stage and when starting a complicated bit of code I might draw more boxes and arrows. But I almost never write down code apart from a tricky fragment, and the whole point of design is to minimize tricky code.

Anyway, rapid development often means playing around in "executable pseudocode" getting the algorithm(s) right. Python is my current executable pseudocode of choice.

calebjosue2y ago

I'd like sketching algorithms and ideas in paper, because I can focus on the idea I'd want to try, with no syntax (I write a combination of Pseudocode-haskell-math combination) and programming language peculiarity getting in my way. But eventually those ideas need to be typed in a particular programming language using a computer, if some idea needs refinement it is very helpful for me to launch a debugger or a REPL session. As Leslie Lamport would say: Thinking above code.

potta_coffee2y ago

Sometimes I have to write code that I don't fully understand before I sit down to type it in. This happens less often as I've become more experienced, but at such times I find it useful to code on paper in order to scratch out relationships between things, or determine what functions or methods I'll need to accomplish a specific task. Most of the time these days I already know how to code the thing and I just sit down and bang it out.

b200002y ago

I wrote firmware on paper for years while drinking wine in a bar. I wrote some of my best code and fixed some of my hardest bugs while doing that. You can tear paper, tape it together. It can get filthy. You can use all kinds of pens. It is cheap and you can create any size overview you want. And you can look important and get asked questions. You can ruminate on problems for longer time such that you are 99% sure it will work.

1 more reply

eternityforest2y ago

I don't use paper much, even though I suspect I really should, because of the mental health benefits various people cite.

Also, I spend almost as much time researching as I do actually coding.

I don't tend to experiment and rewrite much, I would rather spend that time researching and getting the architecture and APIs right.

Code can always be refactored, interfaces and data structures can only be changed if you updated all the other stuff that touches them.

pjacotg2y ago

I recently listened to an interview with Leslie Lamport where he said you should write a description of your program in prose before writing any code. So not exactly programming on paper, but part of the process of thinking about what you're going to do can be captured on paper.

He has a saying I like, "If you think without writing you only think you're thinking"

1 more reply

gsuuon2y ago

I've done variations of this, including using an e-ink monitor outdoors. Type driven design works well with pen and paper. Sketch out the types, sketch out the function signatures. It's great for bringing some non-intrusive work with you to social things.

broadwayinc2y ago

I do sometimes. When it's a complex system that I'm building, I draw out some arrows and rough ideas of classes and functions.

ttymck2y ago

No I don't, not on paper. I design systems with drawings, but that's on the computer.

j / k navigate · click thread line to collapse

9 comments

rzzzwilson2y ago

Anyway, rapid development often means playing around in "executable pseudocode" getting the algorithm(s) right. Python is my current executable pseudocode of choice.

calebjosue2y ago

potta_coffee2y ago

b200002y ago

1 more reply

eternityforest2y ago

I don't use paper much, even though I suspect I really should, because of the mental health benefits various people cite.

Also, I spend almost as much time researching as I do actually coding.

I don't tend to experiment and rewrite much, I would rather spend that time researching and getting the architecture and APIs right.

Code can always be refactored, interfaces and data structures can only be changed if you updated all the other stuff that touches them.

pjacotg2y ago

He has a saying I like, "If you think without writing you only think you're thinking"

1 more reply

gsuuon2y ago

broadwayinc2y ago

I do sometimes. When it's a complex system that I'm building, I draw out some arrows and rough ideas of classes and functions.

ttymck2y ago

No I don't, not on paper. I design systems with drawings, but that's on the computer.

j / k navigate · click thread line to collapse