'Teach Naked' Effort Strips Computers From Classrooms
chronicle.com
chronicle.com
You could probably use Powerpoint to simulate that, but most professors don't. Even if you do show the intermediate steps, I think the gradual process of watching something being written out (as well as then having the time to write it out yourself) let's it sink in better.
Even something like having to decipher the professor's handwriting contributes to better understanding. If it's ambiguous what a particular symbol is, you're forced to think harder about the context it's in to figure it out. I'm not saying lectures should be given with obfuscated notes or anything, but that split second of interpretation your brain has to do adds value in the end.
60s - write a 5000 word essay on the causes of the civil war
70s - write a 500 word essay on why the civil war was bad
80s - write a poem about how you feel about the civil war
90 - draw a picture about how the civil war was bad
00s - Copy the PowerPoint slide, make CIVIL WAR bold.
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.
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.
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.
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.
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.