With an expressive type system for its teaching
languages, HtDP could avoid this problem to some
extent, but adding such rich types would also take
the fun out of programming.
As we approach the midpoint of the semester, Matthias Felleisen's Turing Is Useless strikes a chord in me. My students have spent the last two months learning a little Racket, a little functional programming, and a little about how to write data-driven recursive programs. Yet bad habits learned in their previous courses, or at least unchecked by what they learned there, have made the task harder for many of them than it needed to be.
The essay's title plays off the Church-Turing thesis, which asserts that all programming languages have the same expressive power. This powerful claim is not good news for students who are learning to program, though:
Pragmatically speaking, the thesis is completely useless at best -- because it provides no guideline whatsoever as to how to construct programs -- and misleading at worst -- because it suggests any program is a good program.
With a Turing-universal language, a clever student can find a way to solve any problem with some program. Even uninspired but persistent students can tinker their way to a program that produces the right answers. Unfortunately, they don't understand that the right answers aren't the point; the right program is. Trolling StackOverflow will get them a program, but too often the students don't understand whether it is a good or bad program in their current situation. It just works.
I have not been as faithful to the HtDP approach this semester as I probably should have been, but I share its desire to help students to design programs systematically. We have looked at design patterns that implement specific strategies, not language features. Each strategy focuses on the definition of the data being processed and the definition of the value being produced. This has great value for me as the instructor, because I can usually see right away why a function isn't working for the student the way he or she intended: they have strayed from the data as defined by the problem.
This is also of great value to some of my students. They want to learn how to program in a reliable way, and having tools that guide their thinking is more important than finding yet another primitive Racket procedure to try. For others, though "garage programming" is good enough; they just want get the job done right now, regardless of which muscles they use. Design is not part of their attitude, and that's a hard habit to break. How use doth breed a habit in a student!
Last semester, I taught intro CS from what Felleisen calls a traditional text. Coupled that experience with my experience so far this semester, I'm thinking a lot these days about how we can help students develop a design-centered attitude at the outset of their undergrad courses. I have several blog entries in draft form about last semester, but one thing that stands out is the extent to which every step in the instruction is driven by the next cool programming construct. Put them all on the table, fiddle around for a while, and you'll make something that works. One conclusion we can draw from the Church-Turing thesis is that this isn't surprising. Unfortunately, odds are any program created this way is not a very good program.
(The sentence near the end that sounds like Shakespeare is. It's from The Two Gentlemen of Verona, with a suitable change in noun.)
The team is in the weight room. Your coach wants you to work on your upper-body strength and so has assigned you a regimen that includes bench presses and exercises for your lats and delts. You are on the bench, struggling.
"Hey, coach, this is pretty hard. Can I use my legs to help lift this weight?"
The coach shakes his head and wonders what he is going to do with you.
Using your legs is precisely not the point. You need to make your other muscles stronger. Stick to the bench.
If athletics isn't your thing, we can tell this story with a piano. Or a pen and paper. Or a chessboard.
I love this answer from Matthias Felleisen on the Racket users mailing list today:
The book emphasizes systematic design. You can solve this specific problem with brute force regular-expression matching in a few lines of code. The question is whether you want to learn to solve problems or copy code from mailing lists and StackOverflow without understanding what's really going on.
Students today aren't much different from the students in the good old days. But the tools and information so readily available to them make it a lot easier for them to indulge their baser urges. In the good old days, we had to work hard to get good grades and not understand what we were doing.
Here is another interesting piece from The New Yorker, this time on an example of science in action. Jon Krakauer is the author of Into the Wild, about adventurer Chris McCandless. Eighteen months ago, he published a claim that McCandless had likely died as a result of eating the seeds of Hedysarum alpinum, known as wild potato. Krakauer's theory was based on lab analysis of seeds from the plant showing that it contained a particular toxic alkaloid. A critic of the claim, Tom Clausen, suggested that Krakauer's theory would be credible only after being subjected to more thorough testing and published in a peer-reviewed journal.
So that's what Krakauer did. He worked with the same lab to do more thorough testing and found that his toxic alkaloid theory didn't hold up after all. Instead, detailed analysis found that Hedysarum alpinum instead contains an amino acid that acts as an antimetabolite and for which toxicity in animals has been well documented. This work went through peer review and is being published next month in a scientific journal.
That's how science works. If a claim is challenged by other scientists, it is subjected to further tests. When those tests undermine the claim, it is withdrawn. Often, though, the same tests that undermine one hypothesis can point us in the direction of another and give us the information we need to construct a better theory.
A cautionary lesson from science also jumps out of this article, though. While searching the scientific literature for studies as part of the re-analysis of Hedysarum alpinum, he found a paper that pointed him in the direction of toxic non-protein amino acids. Krakauer writes:
I had missed this article in my earlier searches because I had been looking for a toxic alkaloid instead of a toxic amino acid. Clausen had been looking for a toxic alkaloid as well, when he and Edward Treadwell reported, in a peer-reviewed paper published in the journal Ethnobotany Research & Applications, that "no chemical basis for toxicity could be found" in H. alpinum seeds.
Clausen's team had been looking specifically for alkaloids, but then concluded more generally that "no chemical basis for toxicity could be found". This claim is broader than their results can support. Only the narrower claim that they could find no chemical basis for alkaloid toxicity seems warranted by the evidence. That is probably the conclusion Clausen's team should have drawn. Our conclusions should be as narraow as possible, given the data.
Anyway, Krakauer has written a fascinating article, accessible even to a non-biologist like me. Check it out.
In one sentence:
Unless you tackle a problem that's already solved, which is boring, or one whose solution is clear from the beginning, mostly you are stuck.
This is from Alec Wilkinson's The Pursuit of Beauty, about mathematician Yitang Zhang, who worked a decade on the problem of bounded gaps between prime numbers. As another researcher says in the article,
When you try to prove a theorem, you can almost be totally lost to knowing exactly where you want to go. Often, when you find your way, it happens in a moment, then you live to do it again.
Programmers get used to never feeling normal, but tackling the twin prime problem is on a different level altogether. The same is true for any deep open question in math or computing.
I strongly recommend Wilkinson's article. It describes what life for untenured mathematicians is like, and how a single researcher can manage to solve an important problem.
... write for undergraduates. Why?
Last fall, Steven Pinker took a stab at explaining why academics stink at writing. He hypothesizes that cognitive science and human psychology explain much of the problem. Experts often find it difficult to imagine that others do not know what experts know, which Pinker calls the curse of knowledge. They work around the limitations of short-term memory by packaging ideas into bigger and more abstract units, often called chunking. Finally, they tend to think about the things they understand well in terms of how they use them, not in terms of what they look like, a transition called functional fixity.
Toward the end of the article, Pinker summarizes:
The curse of knowledge, in combination with chunking and functional fixity, helps make sense of the paradox that classic style is difficult to master. What could be so hard about pretending to open your eyes and hold up your end of a conversation? The reason it's harder than it sounds is that if you are enough of an expert in a topic to have something to say about it, you have probably come to think about it in abstract chunks and functional labels that are now second nature to you but are still unfamiliar to your readers--and you are the last one to realize it.
Most academics aren't trying to write bad prose. They simply don't have enough practice writing good prose.
When Calvin explained to Hobbes, "With a little practice, writing can be an intimidating and impenetrable fog," he got it backward. Fog comes easily to writers; it's the clarity that requires practice. The naïve realism and breezy conversation in classic style are deceptive, an artifice constructed through effort and skill.
Wanting to write better is not sufficient. Exorcising the curse requires writers to learn new skills and to practice. One of the best ways to see if the effort is paying off is to get feedback: show the work to real readers and see if they can follow it.
That's where undergraduates come in. If you want to become a better writer or a better speaker, teach undergraduates regularly. They are about as far removed as you can get from an expert while still having an interest in the topic and some inclination to learn more about it.
When I write lecture notes for my undergrads, I have to eliminate as much jargon as possible. I have to work hard to put topics into the best order for learners, not for colleagues who are also expert in the area. I have to find stories to illuminate ideas, and examples to illustrate them. When I miss the intended mark on any of these attempts, my students will let me know, either through their questions or through their inability to perform as I expected. And then I try again.
My lecture notes are far from perfect, but they are always much better after a few iterations teaching a course than they are the first time I do. The weakest parts tend to be for material I'm adding to the course for the first time; the best parts tend to be revisions of existing material. These facts are no surprise to any writer or presenter, of course. Repetition and effort are how we make things better.
Even if you do not consider yourself a teacher by trade, if you want to improve your ability to communicate science, teach undergrads. Write lecture notes and explanations. Present to live students and monitor lab sessions. The students will reward you with vigorous feedback. Besides, they are good people to get to know.