Hacker News Reader

> if you can't run the program in your head, then you simply don't understand what's going on

Agreed, and sometimes it's surprisingly tricky to describe what's happening not in terms of the coding abstractions we all know and love, but just in plain English.

I remember I did a contract years ago for a PhD student which was basically doing some statistical analysis of a massive dataset. When I was doing progress reports she'd often drill down and ask, out of genuine curiosity (she was an academic, go figure :-) just how the computer was doing the things I was describing.

I couldn't use abstractions like 'well I just loop over this set and accumulate x and...' because that's gibberish to her - so I had to kind of break down what was actually going on in plain English (obviously with a degree of abstraction from the hardware etc). I did so very awkwardly because I was used to just 'thinking in code', but remember it was very helpful for me to be forced to do this because it really tested that I actually understood what my algorithms were doing.

But obviously there's a limit to the usefulness of this line of thinking. Abstractions are always present - ad adsurdium, we'd never talk about electrons flying around etc. It ceases (except in extremely rare exceptions) to be useful to describe what is actually happening in more detail than 'this black box does X, and I use it with another black box that does Y to achieve Z' right about the level where you're writing 'real' applications with frameworks and whatnot.

I wonder to what extent you were just finding actual abstractions that the two of you could share. "For each number/thing in this list, you do a calculation" is an abstraction from an old school "for (i = 0; i < n; i++)" loop. A lot of modern conveniences in programming are abstractions that ordinary language has had forever.

A lot of people in programming think of abstraction in terms of AbstractFactoryFactories or LifecycleConfigurators and then start to complain about architecture astronauts and leaky abstractions. But there are more basic abstractions that we use every day, which are perfectly precise, don't leak[1] and are near-indispensible.

[1] Except perhaps in terms of performance.

I've told my students that if you can't run the program in your head, then you simply don't understand what's going on. You haven't learned anything.

Absolutely. A coworker has a similar version of that line, which I've committed to memory:

"If you don't understand precisely what you need to do, what makes you think you can tell a computer how to do it?"

I also briefly taught programming, and that's a line I've used more often than I'd like. Another thing I've noticed is that IDEs tend to encourage beginners to perform much random fiddling of code that doesn't work, often creating a mess in the process.

I would be careful here - when I studied organic and physical chemistry, I was very surprised to discover how much of the discipline was empiric. X + Y + heat = Z. Why? Mmmm, ask a physicist.

I completely agree with you here. It's also quite good to practice optimizing or iterating over your implementation of something mentally before commit to typing it out, certainly before repeatly running your changes until it just works.

You really think improvisational programming is equivalent to data entry? Have you ever done data entry?

I don't think improvisational programming (as I understand it) is equivalent to data entry. That also was not what I was describing.

You seem to be a fairly adept programmer. The concept of improvisational programming makes sense for you - you draw on years of experience and training (formal, or not) to feel out a concept when you have a goal in mind but no clear way to get there. You probably perform many small experiments to learn more about the intricacies of whatever you are working on. You can do all this because you've progressed past the beginning stages.

Most beginners simply aren't capable of this. There are too many blind alleys. Too many traps. It's not that I discourage self-directed learning, experimenting or researching - all are essential to learning computer science. Rather I've seen far too many students simply resort to guess and check methodology when face with a problem. This isn't the kind of guided exploration that comes with experience but: "Adding 1 to that index didn't work - I wonder if 2 will? 3? 4? 10? Oh! 12 works! Great - I'm done!"

Incidentally, I have done data entry. My first computer was an Apple II. I used to type in programs from magazines without really understand what they were doing. Even worse, I typed in raw hexadecimal program data. I know what it's like to type something in you don't understand, find out it's wrong, tweak it, and try again ad infinitum (or so it seemed). "Does A9 work? What about AA? AC? ...AF works! Great - I'm done!"