Hard to believe it's Friday. I spent today divided pretty evenly among: 1) secret stuff involving the contest, 2) preparing for my class, and 3) taking stock and a few next directions for the interoperability paper. The secret stuff I obviously can't talk about, and I'd like to hold off on discussing the interoperability stuff for at least a while, but I do have something to say about teaching.
I'm going to be teaching my first intro CS class starting on Monday, and I'm going to do it using the How to Design Programs teaching methodology. This is my first time teaching it myself, but I've been involved in classes that taught that way many times, and while it's amazing how effective it is (particularly since the book lulls you into thinking it's kids' stuff the whole way through) one troubling problem always crops up. Intro classes always have a few people who have done a lot of programming in high school or elsewhere and are taking the intro class even though in their view they don't need to because they feel like they know whatever introductory material you could possibly be teaching already. Maybe they've even got AP tests or chess-playing programs or something that serve as evidence. These people tend to see the HtDP curriculum as a joke - "why are we programming in a goofy language like Scheme, where you can't even assign values to variables and there are no loops and you don't get printf and you've got all these silly parentheses? I wrote a chess player once, I'm obviously a computer genius who ought to be trusted the raw power of do while loops and languages that don't baby you by checking to see if you're writing outside array boundaries!"
The traditional way to deal with these students in the classes I've observed has been essentially to ignore them. The teacher knows best, and students ought to understand that their professors do in fact realize that there exist languages with for loops in them and chose against those languages for a good reason. There are a couple of problems with this tack in my view. First, there's a deeply engrained notion in just about everyone that if you're learning how to program and you're learning language X then you must necessarily be learning how to program IN language X and that any skills you pick up in the process don't apply to languages Y and Z, so it's a waste of time to learn any programming skills in a language you won't be using to write real programs. I've heard this opinion expressed in no uncertain terms by many people with PhDs in computer science, and in fact at my undergraduate university the electrical engineering department used to offer their own intro to programming class specifically because they thought it was a waste of time for their students to learn any language other than C. If it's a majority opinion among PhDs that you can't learn anything useful about programming by studying Scheme, surely we can't blame freshmen for thinking it too. Second, when people who have had a taste of a C-like language see Scheme as it's presented in HtDP, they can't really help but notice that you can't really do anything in it. Sure, we teachers know that they can do everything they need to for us to be able to teach about natural recursion or whatever, but they're thinking "video games! graphics! inline assembly!" and, well, none of the teaching languages anywhere in HtDP let you make any kind of practical program of more than a schoolwork interest. If we don't even tell people that these things are possible, how will they know? And can we blame them for not thinking they're learning anything useful?
I'm not sure exactly what I'd propose to do about it. I think I may have a little spiel at some point in the first class about how computer languages aren't like human languages in some ways, and that the skills you learn in one computer language really do transfer over to others to a much greater degree. I'm also going to try as hard as I can to make homeworks and labs that have students doing things they can imagine really being useful and/or cool, like the 3D lab I did last year that I'm pretty proud of (that was taught in the fourth week of class to people who had no prior programming experience, and most people got the whole thing working!). But I feel like that may not be enough. When I teach this class again in the fall, I'm thinking about making Practical Common Lisp an optional supplementary text and giving people extra credit for doing the practical sections of that book in Scheme (of course I'd have to help them with that, but that's fine with me). That might do it.
Has anyone out there taught a class and figured out a solution to this problem? Or been a student in a class where the teacher solved it particularly well? I'd like to hear about it if so.
I'm going to be teaching my first intro CS class starting on Monday, and I'm going to do it using the How to Design Programs teaching methodology. This is my first time teaching it myself, but I've been involved in classes that taught that way many times, and while it's amazing how effective it is (particularly since the book lulls you into thinking it's kids' stuff the whole way through) one troubling problem always crops up. Intro classes always have a few people who have done a lot of programming in high school or elsewhere and are taking the intro class even though in their view they don't need to because they feel like they know whatever introductory material you could possibly be teaching already. Maybe they've even got AP tests or chess-playing programs or something that serve as evidence. These people tend to see the HtDP curriculum as a joke - "why are we programming in a goofy language like Scheme, where you can't even assign values to variables and there are no loops and you don't get printf and you've got all these silly parentheses? I wrote a chess player once, I'm obviously a computer genius who ought to be trusted the raw power of do while loops and languages that don't baby you by checking to see if you're writing outside array boundaries!"
The traditional way to deal with these students in the classes I've observed has been essentially to ignore them. The teacher knows best, and students ought to understand that their professors do in fact realize that there exist languages with for loops in them and chose against those languages for a good reason. There are a couple of problems with this tack in my view. First, there's a deeply engrained notion in just about everyone that if you're learning how to program and you're learning language X then you must necessarily be learning how to program IN language X and that any skills you pick up in the process don't apply to languages Y and Z, so it's a waste of time to learn any programming skills in a language you won't be using to write real programs. I've heard this opinion expressed in no uncertain terms by many people with PhDs in computer science, and in fact at my undergraduate university the electrical engineering department used to offer their own intro to programming class specifically because they thought it was a waste of time for their students to learn any language other than C. If it's a majority opinion among PhDs that you can't learn anything useful about programming by studying Scheme, surely we can't blame freshmen for thinking it too. Second, when people who have had a taste of a C-like language see Scheme as it's presented in HtDP, they can't really help but notice that you can't really do anything in it. Sure, we teachers know that they can do everything they need to for us to be able to teach about natural recursion or whatever, but they're thinking "video games! graphics! inline assembly!" and, well, none of the teaching languages anywhere in HtDP let you make any kind of practical program of more than a schoolwork interest. If we don't even tell people that these things are possible, how will they know? And can we blame them for not thinking they're learning anything useful?
I'm not sure exactly what I'd propose to do about it. I think I may have a little spiel at some point in the first class about how computer languages aren't like human languages in some ways, and that the skills you learn in one computer language really do transfer over to others to a much greater degree. I'm also going to try as hard as I can to make homeworks and labs that have students doing things they can imagine really being useful and/or cool, like the 3D lab I did last year that I'm pretty proud of (that was taught in the fourth week of class to people who had no prior programming experience, and most people got the whole thing working!). But I feel like that may not be enough. When I teach this class again in the fall, I'm thinking about making Practical Common Lisp an optional supplementary text and giving people extra credit for doing the practical sections of that book in Scheme (of course I'd have to help them with that, but that's fine with me). That might do it.
Has anyone out there taught a class and figured out a solution to this problem? Or been a student in a class where the teacher solved it particularly well? I'd like to hear about it if so.
posted by Jacob Matthews at
22:27
6 Comments:
I think I may have a little spiel at some point in the first class...
I don't have specific ideas, but one thing to keep in mind is that "big picture" ideas mean much more to students towards the end of the course rather than the beginning. For example, John Clements told me that in his first time teaching intro, he started with a disastrous first lecture talking way over the heads of all the students about the big picture.
Also, since you have (most of) the students captive for the entire semester, you don't necessarily have to worry about preventing them from fighting you right away. Maybe it's just a necessary part of the process, and you have to ride it out for a while until they've been exposed to enough material to be ready for things like "how to apply data design in other contexts than e.g. Intermediate Scheme w/lambda."
The best teachers I've had know what not to say as much as they know what to say.
By
Dave Herman, at 00:16
Here's a spiel I've given multiple times when this subject has come up. You don't learn to fly in a 747, and you don't learn to drive in a semitruck or formula one racecar. You learn to fly in a piper cub, and learn to drive in a ford sedan with automatic transmission. This is desipite the fact the professional drivers drive semitrucks and professional pilots fly 747s.
Once you get the basics down- and the basics do transfer, wether it be flying, driving, or programming- then you can graduate to the bigger, more powerful, "professional" programming languages.
The problem with learning to fly in a 747 is that it has an insane amount of information and control available to the pilot. Instead of the lone gas gauge a Piper Cub has, a 747 may have a dozen, detailing not only how much fuel is left, but where it is. Now, a professional pilot can use all the control and not get overwhealmed by the amount of information available- it's an advantage (to the professional, experienced pilot) to be able to adjust the trim of the plane in flight by changing which fuels takes the engines are pulling gas from. The poor student, who just wants to make sure they're not about to run out of fuel, however, is overwhealmed.
If you're talented, you can learn to fly in a 747. But it's a lot harder. And simply because you managed to shepard a 747 from Midway to O'Hare (and most of the programs they've written are about that difficult) doesn't mean they know all there is to know about flying. Or even basic stuff that doesn't involve not hitting things, like the correct way to approach a landing field, or how to navigate, how to fly by instrument, how to recover from a stall, etc.
So, congratulations to those of your students who have spent some time behind the stick of a 747. They are expected to get an A and won't get any slack cut for them because this class should be a breeze. That isn't to say you don't have things to learn here. Just less than everyone else. To everyone else, let me introduce you to the programming equivelent of the Piper Cub.
The other peice of advice I have is to challenge them. Not make work- students can smell make work a mile away. Have them write real world programs, for you or other people. When I was in Intro to Comp Sci (and I was one of those students you mentioned- by age 18 I had already been programming for 10 years, and had taken Comp Sci AP in highschool, and had chess programs as demonstration), my professor had me write (for the privelege of skipping the discussion classes) his grading programs. If they're as talented as I am, blowing through the entire course should take them about 2 weeks or so, at most. Which gives you 10 more weeks to get real work out of them.
For the remainder, it's about ego. "This class should be about me, about how smart I am, about how advanced I am." Slap them down and move on.
By
Anonymous, at 10:41
I'm ashamed to admit I was one of those annoying students.
The few programming classes I've taught or been in had no Bell curve. Part of the class already knew the material, and the other part barely knew the prerequisites. It's really hard to teach this sort of distribution. Perhaps you can enlist the help of the top group in teaching the bottom group? Explaining something is one of the best ways to solidify it in your own mind.
I think you're on the right track with your 3D lab. People want to write interesting programs, not compute Fibonacci numbers. I've tried poviding most of the pieces of a program to students and having them fill in the fun bits. The experienced students go hog-wild adding their own bells and whistles, and they may be interested enough to delve into the bits you've provided. One of the best things you can do for students is to provide them with a large corpus of good code that solves interesting problems. I spent years as a kid copying code out of books and magazines without understanding it fully.
For your students who may doubt the applicability of Scheme: several video game companies including the one I'm at use Scheme or Lisp as a scripting language. In my limited experience it isn't generally pretty (or complex) Scheme code, but there it is.
By
Anonymous, at 12:14
James: no shame in that, I suspect most of us were that kid too (I certainly was). I'm mostly motivated by the desire to get kids like I was to pay attention; once I got the deep ideas from my programming languages class I realized that I'd been taught all of them before in intro and had just not paid any attention.
Dave, Brian, James: thanks for these suggestions. I think I'll probably say something brief along the lines of Brian's suggestions on Monday, and plan for more extended discussion of how this stuff applies to the wider world towards the end of the course, while trying to make all the labs rooted in practical tasks. Your answers have been really very helpful, thank you.
By
Jacob Matthews, at 12:42
I think it'd be really enlightening to tell them that a language that allows you to do as much as C allows you to do is not necessarily desirable at the highest levels of programming skill.
I was a big fan of C my freshman year before I understood that. My intro class was in C++, though, so we had the opposite problem of simply loosing the everyone but the middle 10% of students.
Anyway, I think stressing that point might go a long way with experienced students that don't have too much of an "I don't want to have my hand held" attitude. You could give them papers like Goto Considered Harmful and allow extra credit critiques of sorts.
I feel like I'm a pretty good programmer (at least compared to college Freshman) and I want my language to hold my hand as much as possible. I don't have the time to debug silent array out-of-bounds errors. They won't either when they start writing real programs.
By
Mike Machenry, at 08:37
Freshman expect to be taught specific technologies (Java, HTML, DBs). Every class, especially intro CS, should explain that technologies change very quickly, but the underlying ideas remain the same. That's the difference between CS and a 2-year IT certificate. Scheme is useful because it's small, simple and capable of expressing nearly all PL concepts. I would often compare snippets of Scheme vs. Java & C to illustrate PL concepts. Some get it, others just want to program in Java.
By
Anonymous, at 12:12
Post a Comment
<< Home