Programming on paper is amazingly bad (I've done it, mostly for exams). Even worse, you will teach programmers that you develop linearly (from top to bottom) and once a line of code is written it cannot be changed. Those are terrible coding habits.

Really brute forcing a solution isn't bad for a first run. If they done it, tell them to make it faster or smaller. Given that they've solved it once, they should understand the problem better.

I write pseudocode on paper before I implement anything, and it has helped me tremendously. In fact, I think programming on paper encourages nonlinear programming. You can DRAW! Use lines and arrows to code blocks. Sure, it might get messy, but doing it on paper gives you a better idea of how your algorithm should work. You make less mistakes because making a mistake is more costly (you have to erase/mark out the mistake), so you tend to be more careful.

When I got into professional programming compilers were a round trip to the machine room away. So one thing we did to save time was to 'desk check' our code. This usually meant a simple simulation using a piece of paper to hold the variables, crossing them out when they were overwritten. At some point I could do it for limited pieces of code by just simulating the code in my head.

Simulating code in your head goes a long way towards writing solid code, you'll be able to hold a model of the data and your code together and see whether it will work or not and fix bugs before your first compile.

I agree, if you can program on paper, you can program on anything. Paper programming forces you to slow down and think.

I'm a CS student the University of Texas, and quite a few of our professors, especially at the entry level programming courses, disallow students from brining computers to class and all our programming tests are all written. This encourages patient THINKING and not sporadic TINKERING.

And about powerpoint: I dislike it because most people do it wrong. The lecture should be guiding the powerpoint, but most people allow the powerpoint to guide the lecture.

Yes. Most people have taken Powerpoint and tried to use it as a replacement for having 3x5 notecards with major points on them so that they don't get lost during a lecture/speech. Unfortunately that is the poorest use of Powerpoint.

But this comes hand-in-hand with the way we choose professors. They aren't usually chosen for their teaching or speaking skills, just for their knowledge and expertise in a particular field.

I program better on a computer because despite my Catholic elementary school penmanship training my hand begins to ache after a few minutes of handwriting, and I write slowly. The longer I have to hold a pen or a pencil the more difficult it becomes to concentrate on anything but how uncomfortable my hands are.

I reach for pencil and paper all the time for solving problems, but if I can't write what has to be written in less than 5-10 minutes it's not worth it.

This maybe true, but I cringe at the thought of writing code on paper.

Well, hopefully nobody is asking you to write legal Java down to the last namespace and semicolon on paper. (I know some classes do this; I think it's foolish.) But writing semi-legal Scheme or pseudocode on paper is easy and no more strange or demanding than doing mathematics on paper. I don't think it deserves a cringe.

Also, if it's some small degree harder to actually physically write the program, I'm not sure that's a bad thing in terms of learning; it encourages you to do more thinking and understanding and less fly-by-wire programming and testing.

Absolutely. My early programming courses all had code-writing on the written exams, all in Scheme. (I think Scheme is particularly well-suited to paper, though, because of its minimal syntax and its "general recursion for everything" approach.)

Programming on a computer---particularly in a REPL language like Scheme---tempts one to "just run it". Writing a program on paper requires reflection and planning: good skills, I think.

The high school Computer Science AP exam asks you to do this with Java. Missing a semicolon is a minor deduction, but it is still a deduction.

I've had to write 100% legal Matlab, Java and C++ in tests (I study Computer Engineering). All of our exams are on paper only.

Actually, I even had a multiple choice question which asked whether in Matlab it was legal to start a variable name with a number. Not the most important thing to know, IMHO, but introductory programming classes here tend to focus on syntax so that the engineering students can get something done quickly.

Regarding math on paper, I actually find it's easier to do math on computer than on paper. Quick and easy calculations (e.g., less than half a page) are often faster on paper, but the long and involved ones require a computer to manage.

I might have different feelings if I didn't use emacs.

Are you one of those people who TeX's their notes while sitting in class? I'm always amazed by that. Wish I could pull it off :)

Long calculations are a pain, but I find doing it by hand is good, so that I can go back and find mistakes. I tend to use one long scratch pads, so that I have a sort of ongoing, live revision control. When I use LaTeX I tend to erase stuff, because I want LaTex to look nice, and of course the erased parts might have been useful later.

I never actually developed note-taking skills. After a semester or two, I gave up on even trying.

Basically, my calculations usually look like this:

interesting quantity < mess[0] < mess[1] < ... < mess[n] < final result

I've found it's very easy to copy mess[j] to a new line, edit, and repeat. It's harder to rewrite mess[j] on paper. Storing complicated expressions in emacs registers is also quite nice.

I wrote code in various languages on paper for tests in college. Even C++ and Java are not horrible if the teacher just asks for you for a code snippet that demonstrates one thing. Obviously "write a whole program that works" assignments were done on a computer :)

I had to write code in college for tests. Didn't bother me at all.