> 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.
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.
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).
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.
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.
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.
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.
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.
I believe the person doing this was ztratar. If you go to the original post (http://www.zachtratar.com/tesla.html#.VjbLMY9Viko) and look at the comments, you'll see he posted a 1-year update. It sounds like he got good results but found the result not worth the effort. If anyone's interested in potentially continuing with this experiment, please PM me. This is something i'm quite interested in.
This is something I've been thinking about for a while. However, I approach it from the perspective of "Can we come up with a way that we can combine coding with meditation?"
I'd like something similar to soroban where coding can act as an entirely mental activity. My fascination with terse languages like J and K arise from this same ideal, being able to code only in your head.
I'd be curious to hear other people's thoughts on the desirability or feasibility of some form of algorithms or coding done entirely mentally, as I haven't discussed this with anyone to date.
I've always enjoyed going for a walk to ponder problems, and then coming back to my desk to "pour out" a solution I have in my head. Sometimes it works right the first time, and other times the process of making everything more explicit and typing it out reveals blind spots in my original thinking.
I started learning K nearly a year ago, and I've found it's much more amenable to coding in my head. Programs work on the first try more frequently. Very satisfying, once you get used to its primitives.
Out of curiosity, which jhani states have you reached and what specific anapanasati technique do you use (focus on breath at nostrils, breath throughout the body, kasina, etc). I'm working to achieve first Khama currently, but getting a bit stuck in access concentration.
I've used Shaila Catherine books for guidance and instructions. It's hard to say which jhanic states exactly because I practice alone with no teachers. I would guess from first to third but not for long periods of time. I have experienced piti and after that entered 'equanimity' jhanic state, subtle but alert and content concentration.
I highly recommend the book Focused and Fearless, I haven't seen such clarity on meditation anywhere else, except maybe Buddhist texts but they can be cryptic and poorly translated.
My technique is comfortable freestyle sitting (as opposite to lotus that gives me pain and takes away from concentration) and breath counting from 1 to 10 and 10 to 1 until I reach more relaxed breathing, then I switch to counting 1-1 on inhale, 1-1 on exhale, repeat until 10 and backwards, this reduced mental activity and keeps me on a) breath at nostrils and b) concentration with counting. After 15-20 minutes I usually start hitting Jhanic states with piti coming in first and then going away to enter more subtle higher absorption.
But yeah, get the above book, I am not much of a guide, I was actually lucky to hit piti within several days of Anapanasati meditation and Jhanic states within a week. I hear that some people struggle for months.
- Talking to an imaginary friend as a way to increase understanding: http://the-programmers-stone.com/the-original-talks/day-1-th...
- Rubber duck debugging: http://c2.com/cgi/wiki?RubberDucking
- Characteristics of an effective internal dialogue: http://journalpsyche.org/articles/0xc091.pdf