In The Art Of Computer Programming, one of the most influential and comprehensive series of books on the subject, Knuth uses a fictional assembly language called MIX in the examples. The reader does "just run the program in their head."
In Software Tools Brian Kernighan and P.J. Plauger describe a pseudo-language called RATFOR (Rational Fortran), and then throughout the book implement RATFOR in itself.
Getting feedback while learning to program has a lot of value, but so does learning to think through code in your head. People old enough to remember when you had to wait a day to run your program and get results back (very slow turnaround) know the value of that skill, we used to call it "desk checking" -- reading through your code and running it in your head and on paper.
This is itself a skill people need to learn, that I'm not sure is possible with pseudocode and no prior experience. Too easy to gloss over details without actually running it to learn where your blind spots are.
I did this workshop a decade or so ago where I learned my co-workers don't do this, and never did learn how they understand code otherwise. One of them mentioned he didn't even realize this was a thing.
> never did learn how they understand code otherwise.
This particular statement interested me.
In code review, I always am a stickler that "if I need to run the code in my head to prove something about it for me, I want to see that in a unit test - I shouldn't have questions about the code that aren't already answered by the tests"
When I took an introductory programming class at Sacramento City College in fall 2004 during my senior year of high school, we spent the first half of the semester designing our programs using flowcharts and pseudocode. We were encouraged to check the logic of our flowcharts and pseudocode. In the second half of the semester, we implemented those programs in C++.
I haven’t seen this pedagogical practice in any other introductory course I’ve seen since. I believe it’s a holdover from the early days of computing, when programmers didn’t have access to personal computers or even interactive computing, which meant that programmers needed to spend more up-front time on design. Think of the punchcard era, for example.
I teach introductory programming in C++ at Ohlone College in Fremont, and I have my students write C++ on Day 1, starting with “Hello World” and going from there without flowcharts.
I think it's for all intents and purposes impossible to program like this in this century. Like imagine just writing x + y in C++. Are you seriously going to enumerate every declaration of operator+ in the translation unit in your head to see if it's eligible (don't forget ADL)? And then every single possible implicit conversion or promotion that could make other ones eligible? And then go through all the overload resolution rules that practically no humans have memorized (with any template instantiations that may come into play) to figure out if the declaration you wanted is actually the best match? That's before you even look at its definition...
In one of my classes they had to explicitly ban people from using Python in their psuedocode submissions lol. (Generally this meant things like "no list comprehensions" and similar Python syntax details).
Not at all. It's called learning computer science. Just like you can do calculus without simulation, you can understand the semantics of a computer program without running it. It might make it harder, but running it is only a didactic tool - as Knuth did, you should be able to prove it correct without ever running it.
I never see anyone learning to program using pseudocode (which isn't runnable to get feedback).
If they used pseudocode, were they just run the program in their heads?