March 02, 2015 4:14 PM
Knowing When We Don't Understand
Via a circuitous walk of web links, this morning I read an old piece called Two More Things to Unlearn from School, which opens:
I suspect the *most* dangerous habit of thought taught in schools is that even if you don't really understand something, you should parrot it back anyway. One of the most fundamental life skills is realizing when you are confused, and school actively destroys this ability -- teaches students that they "understand" when they can successfully answer questions on an exam, which is very very very far from absorbing the knowledge and making it a part of you. Students learn the habit that eating consists of putting food into mouth; the exams can't test for chewing or swallowing, and so they starve.
Schools don't teach this habit explicitly, but they allow it to develop and grow without check. This is one of the things that makes computer science hard for students. You can only get so far by parroting back answers you don't understand. Eventually, you have to write a program or prove an assertion, and all the memorization of facts in the world can't help you.
That said, though, I think students know very well when when they don't understand something. Many of my students struggle with the things they don't understand. But, as Yudkowsky says, they face the time constraints of a course fitting into a fifteen-week window and of one course competing with others for their time. The habit have they developed over the years is to think that, in the end, not understanding is okay, or at least an acceptable outcome of the course. As long as they get the grade they need to move on, they'll have another chance to get it later. And maybe they won't ever need to understand this thing ever again...
One of the best things we can do for students is to ask them to make things and to discuss with them the things they made, and how they made them. This is a sort of intellectual work that requires a deeper understanding than merely factual. It also forces them to consider the choices and trade-offs that characterize real knowledge.
February 27, 2015 3:37 PM
Bad Habits and Haphazard Design
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.)
February 24, 2015 3:03 PM
Why Can't I Use flatten on This Assignment?
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.
February 21, 2015 11:11 AM
Matthias, Speak to My Students
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.
February 16, 2015 4:15 PM
An Example of Science in Action
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.
February 06, 2015 3:11 PM
What It Feels Like To Do Research
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.
February 05, 2015 3:57 PM
If You Want to Become a Better Writer...
... 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.
January 31, 2015 11:51 AM
Failure with a Purpose
... failure isn't always that informative. You can learn a thousand different ways to fail and never learn a single way to succeed.
To fail for failure's sake is foolish and wasteful. In writing, the awful stuff you write when you start isn't usually valuable in itself, but rather for what we learn from studying and practicing. In science, failing isn't usually valuable in itself, but rather for what you learn when you prove an idea wrong. The scientist's mindset has a built-in correction for dealing with failure: every surprising result prompts a new attempt to understand why and build a better model.
As Grimm says, be sure you know what purpose your failure will serve. Sometimes, taking bigger risks intellectually can help us get off a plateau in our thinking, or even a local maximum. The failure pays off when we pay attention to the outcome and find a better hill to climb.
January 29, 2015 4:27 PM
A Reminder from Marcus Aurelius
... from Book 6 of The Meditations, courtesy of George Berridge:
You are not compelled to form any opinion about this matter before you, nor to disturb your piece of mind at all. Things in themselves have no power to extort a verdict from you.
This seems especially sound advice in this era, full of devices that enable other people to bombard our minds with matters they find Very Important Indeed. Maintain your piece of mind until you encounter a thing that your own mind knows to be important.
January 28, 2015 3:38 PM
The Relationship Between Coding and Literacy
Many people have been discussing Chris Granger's recent essay Coding is not the New Literacy, and most seem to approve of his argument. Reading it brought to my mind this sentence from Alan Kay in VPRI Memo M-2007-007a, The Real Computer Revolution Hasn't Happened Yet:
Literacy is not just being able to read and write, but being able to deal fluently with the kind of ideas that are important enough to write about and discuss.
Literacy requires both the low-level skills of reading and writing and the higher-order capacity for using them on important ideas.
That is one thing that makes me uneasy about Granger's argument. It is true that teaching people only low-level coding skills won't empower them if they don't know how to use them to use them fluently to build models that matter. But neither will teaching them how to build models without giving them access to the programming skills they need to express their ideas beyond what some tool gives them.
We sometimes do a better job introducing programming to kids, because we use tools that allow students to build models they care about and can understand. In the VPRI memo, Kay describes experiences teaching elementary school, students to use eToys to model physical phenomena. In the end, they learn physics and the key ideas underlying calculus. But they also learn the fundamentals of programming, in an environment that opens up into Squeak, a flavor of Smalltalk.
I've seen teachers introduce students to Scratch in a similar way. Scratch is a drag-and-drop programming environment, but it really is a open-ended and lightweight modeling tool. Students can learn low-level coding skills and higher-level thinking skills in tandem.
That is the key to making Granger's idea work in the best way possible. We need to teach people how to think about and build models in a way that naturally evolves into programming. I am reminded of another quote from Alan Kay that I heard back in the 1990s. He reminded us that kindergarteners learn and use the same language that Shakespeare used It is possible for their fluency in the language to grow to the point where they can comprehend some of the greatest literature ever created -- and, if they possess some of Shakepeare's genius, to write their own great literature. English starts small for children, and as they grow, it grows with them. We should aspire to do the same thing for programming.
Granger reminds us that literacy is really about composition and comprehension. But it doesn't do much good to teach people how to solidify their thoughts so that they can be written if they don't know how to write. You can't teach composition until your students know basic reading and writing.
Maybe we can find a way to teach people how to think in terms of models and how to implement models in programs at the same time, in a language system that grows along with their understanding. Granger's latest project, Eve, may be a step in that direction. There are plenty of steps left for us to take in the direction of languages like Scratch, too.