Hacker News new | past | comments | ask | show | jobs | submit login

I think there's something to doing it in your head/on paper. Reminds me of the story told of Don Knuth, clipped here from Quora...

Quote from Alan Kay about Knuth:

When I was at Stanford with the AI project [in the late 1960s] one of the things we used to do every Thanksgiving is have a computer programming contest with people on research projects in the Bay area. The prize I think was a turkey.

[John] McCarthy used to make up the problems. The one year that Knuth entered this, he won both the fastest time getting the program running and he also won the fastest execution of the algorithm. He did it on the worst system with remote batch called the Wilbur system. And he basically beat the shit out of everyone.

And they asked him, "How could you possibly do this?" And he answered, "When I learned to program, you were lucky if you got five minutes with the machine a day. If you wanted to get the program going, it just had to be written right. So people just learned to program like it was carving stone. You sort of have to sidle up to it. That's how I learned to program." - [1]

[1] - http://www.quora.com/How-would-Donald-Knuth-fare-as-a-compet...




From today's perspective, it feels odd that those things existed in many people's life times; to be only allowed 'five minutes' access to a computer. Nowadays if you want to program, you could find a used machine to write code on for five hours of minimum wage, or a new one for twenty.


Or rent a VPS for 45 minutes at minimum wage.


But what about the computer and internet connection to access the VPS?


Yes, my point is that getting access to a Linux server on the Internet which you aren't afraid to accidentally break is easy.


Though it sounds like the right way to go, my personal experience points to the exact opposite.

I'm unfortunately cursed that I have a lot of trouble starting a problem till I really really understand all it's details and the details of my solution. I basically write down exactly what I want and am going to do on paper

I find that my coworkers that start with a vague idea of what they want (without a complete understanding of the system) but work in quick hack->fix iterations produce results significantly faster.

I don't have a huge sample size, but that's simply what I've observed. The person that finishes first is the person that starts typing first. The one that mulls over everything in their head might have a more elegant solution and a clearer git repo.. but they always finish last


Knuth wrote the entirety of the first version of TeX on yellow legal note pads, and then typed it all in, and then started debugging. Ditto for MetaFont. Both are the equivalent of about 10kloc (after the Tangle preprocessor removes the voluminous comments).


I would love a reference about the yellow legal note pad thing.

In reality, writing a program in longhand is something everybody could do -- but because nowadays programming is mostly plumbing, you have to empirically test everything.


I saw it with my own eyes when I was in his office to discuss some typesetter-interfacing issues, but I suppose that's not enough of a reference. Perhaps the story is repeated in an old issue of TuGboat, the journal of the TeX Users Group, but I couldn't find it. Here's a more extensive description from a decade ago though: https://groups.google.com/d/msg/comp.text.tex/9quGg7j6U0k/tl...


I don't know exactly when TeX was written, but back in the ed days before vi and emacs, a yellow legal pad was a substantially better full-screen editor than the line editor. Computers were for executing programs, not editing text.


Knuth developed the first version of TeX in 1978, on the Sail mainframe, a 36-bit DEC PDP-10 with a unique hardware graphics system called Data Disc: a single-platter disk with 32 fixed read/write heads, where each of the 32 tracks contained exactly the 512 X 480 bits that constituted one frame buffer's worth of pixels. The amazing hack was that the rotational speed of the disk was just right so that during each rotation, the raw bits coming off of each head produced a video signal with just the right frequency for piping out through a coax to a completely dumb black-and-white video screen! (Actually, there was a cross-switch in there, so that there could be 64 of these special screen/keyboard units, of which 32 could be in use at a time; in fact, you could walk up to any of them and "grab" the channel that you had been using from a different office, or, for that matter, peek at anybody else's channel.)

Anyway, the custom OS ("Waits") made good use of the Data Disc graphics system: it had a built-in interactive line editor, so that when you were in the shell, you could edit your command line (control-d deletes a character, etc., etc.) and see the result in realtime. (This was years and years before Unix got similar features in tcsh and bash and the readline library). All programs inherited this functionality automatically, so Wait's full-screen editor ("E") was simply built on top of it. (Again, years and years before emacs and vi, and all on a system with a per-process address space of only 256K words (about 1Mb), split evenly between data and code.)

So, to finally answer your question: while Knuth did spend his early years programming on punched-card batch systems (where you pretty much had to write out code long-hand before keypunching it), by the time he had started working on TeX he had been exclusively using a full-screen editor on a graphical display for many years.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: