[krazemon]

> that he was also very much a pencil and paper guy.

I'm curious about this as well. In particular, I wonder whether Feynman wrote out his code on pencil and paper as that's something I've always fantasized about.

[kragen]

You may be interested in the algorithmic notation I designed for writing code with pencil and paper without the usual fuzzy thinking that accompanies pseudocode: http://canonical.org/~kragen/sw/dev3/paperalgo.

[wwwhizz]

I'm probably biased by writing a lot of algorithms in the classical way, but I find your way a lot less readable and very unintuitive. Pseudocode is easy to transform to code; your notation, not so much.

I do applaud your determination of not liking the classical notation and coming up with something different. Maybe it's just that I don't like the syntax of math either (if math would be an API, it would be considered poorly designed, poorly documented and incomplete and inconsistent).

[kragen]

Yes, as I say on the page, I find it less readable, too. But it's much easier to write. And it isn't that hard to transform to code.

[continuational]

I must say i find it more readable than pseudo code; the reason being that all the keywords have been replaced with graphical elements and layout. This means that all the text is essential to the algorithm, which makes it much easier to read for me.

[kragen]

I'm glad you like it! Maybe I'll get used to it in time myself.

I do still use things like "argmin", which you could argue is a "keyword"; by argmin_{x ∈ S} f(x), I mean what you would express in Python as min(S, key=f), which ends up translating to something like this in C:

    int min_found = 0;
    T min;
    U min_item;
    for (iter it = first(S); hasNext(it); it = advanced(it)) {
       U item = itemAt(it);
       T val = f(item);

       if (!min_found || val < min) {
          min_found = 1;
          min = val;
          min_item = item;
       }
    }

    do_whatever_with(min_item);

Maybe this is what someone earlier meant when they said this paper algorithm notation was still too hard to translate into code, but I feel like argmin (over a finite set) is a sufficiently familiar concept that there's no need to spell it out in more detail, and indeed it's a standard library function in Python.

[erikpukinskis]

Go for it! There are definitely situations where I am unsure how to architect something and I'll just go to a coffee shop with a notebook and sketch out pseudocode while I think through different possible implementations.

[fsloth]

I think software engineers pretty much wrote with pencil on paper in the punch card era. Operators then punched the cards. At least in some orgs. This is a bit different than what Feynman did, though, I think.

[todd8]

We generally started with flow charts, sketching them out on regular paper. Once we were ready to write the code, say in FORTRAN, COBOL, PL/I or assembler, we would write out the code on wide pads of paper that had graph paper like markings so that each character was written in a single box and it was easy to keep track of columns.

Every programmer I ever met punched his or her own cards. Key punch operators did exist but were more often employed to enter data at keypunch machines because data was often fed into computers via large stacks of punched cards. Data was virtually always entered in fixed fields on the 80 column punch cards.

The actual keypunching was done most often, during my time, on the IBM 029 keypunch machine. I actually started out on the IBM 026 keypunch, but the 029 was much more suitable for keypunching programs. (The 026, a 1949 design, had no plus sign or parentheses on their keyboards and required a kind of complicated shift where it took multiple key strokes to punch out the correct holes so that the Hollerith code of holes for the parentheses could be entered.) By the time I got to MIT everyone was using the much better 029.

Operating the 029 required first punching a card to be fitted on the control drum of the machine, it controlled tab stops an some other basic field skipping. One also had to learn how to clear card jams and how to quickly duplicate cards or make minor corrections in a card by duplicating parts of a card while inserting new punches at certain locations.

Once a few hundred or maybe a thousand cards were punched you carefully carried the decks in boxes to be assembled into trays of cards that the mainframe operators would take at a submission window. Then it was time for a break while you waited sometimes even overnight depending on your priority for the results, printed on wide sheets of fan-fold paper with alternating green and white stripes on it.

Careful desk checking of the code was required because turn around time was always several minutes and there were times for me when I would not get my output back for hours. Each bug or even syntax error meant starting over back at the keypunch to fix the error. One's source resided in your box of cards, it didn't remain on the machine after your run, successful or not, completed.