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.
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'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.
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 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.
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.
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.
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.
I might have different feelings if I didn't use emacs.
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.
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.