In his latest blog post, @guzdial makes a strong and appealing argument that one can't possibly disagree with. As so often happens with his blog, I have a counter-example. Usually we email, but I'm going to propose doing this publicly instead. Thread: ↵ https://computinged.wordpress.com/2021/02/15/become-a-better-cs-teacher-by-seeing-differently/

One problem that has vexed me for some time now is that students are not very good at understanding undecidability. They may see it in a theory class, but the presentation is so idiosyncratic as to almost be obscurantist. So transfer is almost impossible. ↵

But undecidability is a central problem in programming languages. One cannot understand almost anything about type systems, or garbage collection, without understanding its role (i.e., truth vs provability). So there's a question of how to go about that. ↵

One technique that I employ that has been very insightful for some students is to sprinkle the course homeworks with undecidable problems. The syllabus warns you that they exist (you-know-why @avanhatt) but of course not which ones. ↵

When you run into a difficulty with a problem and think it's because you believe it cannot be solved as defined, you reach out to course staff to ask them whether it's one of those problems. You provide your reasoning. Some Socratic dialog ensues. ↵

If you've correctly identified it for the right reasons, the staff check you off, and you don't have to turn in anything. If you've identified a valid problem but for wrong reasons, we nudge you to the right one. Otherwise, you keep working on it. (We DO get false ids.) ↵

For most problems, most students suspect nothing, and they are right: most of the assignments are not tricky. Only a few are. In fact, in some problems, one sub-problem is decidable and the other one is not. So the pedagogic technique here is "stay on your toes". ↵

There is an extremely important reason for setting things up this way: because that's how the world is. When you encounter a problem in the world, it doesn't come with "decidable/undecidable" tag. You have to figure it out for yourself. ↵

Furthermore, there's little by way of clear "methodology" to figure it out. As with math statement counterexamples (but the other way around), you try to code it up, run into difficulties, step back, and then realize you're confronting an undecidable, then "prove" it. ↵

In addition, programming languages are littered with features that, with small tweaks, can change the decidability of things. Sometimes, you add a "small thing" like types and you go from undecidable to almost trivial. ↵

There's something very important to be said for recreating that experience for students so they have an authentic feel for working with languages, not the packaged experience that so many courses are. They need to carry those lessons out with them. ↵

Mark makes very good points about how frequent questions should be announced, not left dangling to be discovered in hours. I agree; I constantly update assignments and post about them, sometimes even have an FAQ associated with assignments. ↵

But Mark wrote a blanket rule, and I would like to know how he addresses the kind of situation I'm talking about. If the assignment is "Prove that X is undecidable", then yes, the "standard" rules apply. But what if it's "X may or may not be decidable, figure it out"? ↵

Furthermore, the check-in with TAs is critical for multiple reasons. First, students sometimes really do mis-identify problems (in both directions, but *especially* in the lack-of-transfer one: failing to observe an undecidable one). ↵

Second, it's outright cruel to have them work through an assignment to the bitter end that…can't be done. We want them to work long enough to learn, and then stop: every additional line of code, or minute, is almost totally wasted. (And some take a long time anyway!) ↵

Now, all this seems like a big ado about such a strange and weird counter-example that you're not feeling much sympathy here. Besides, as is often the case, Mark is fundamentally right anyway, so why am I fussing so much? ↵

It's because I question a LOT of our standard pedagogy. People in CS Ed are soooo caught up in "authenticity" without questioning what that really means. It seems to end with "nobody got fired for teaching Java/Python", but that's a serious failure of imagination. ↵

A truly authentic educational experience would be FULL of minefields. Of course, undecidability is rare outside certain circles. But issues like big-O complexity are not (inasmuch as real SE needs them, which is prolly less than CS academics like to think). That is: ↵

You are rarely ever given a problem and told "come up with a O[n -> n^2] algorithm". Rather, you're given a problem and asked to find the best complexity/performance (not the same, I know!) you can; and maybe allowed to tweak it to improve that complexity. ↵

When I look at assignments in courses that colleagues hand out, I am stricken by how often they are decontextualized (and boring!), but even more so, how neatly and inauthentically PACKAGED they are. It's all tied up in a bow. Just color between the lines. ↵

No software I've written has EVER come with such a neat little spec. And that's even when I'm the one writing the spec — and believe me, I know something about specification! The problem isn't me or specification, it's the world. ↵

Note: this is NOT an exhortation to do Agile or whatever from day 1. (Maybe that makes sense too, but that's not the flag I'm trying to hoist.) But it is a call for our assignments to not be such damned packaged-up things where nothing can possibly surprise a student. ↵

We can simulate surprise in many ways. It could be through undecidability. At the other extreme, when I've done team software engineering courses, I will randomly move people between teams ("X quit!", "You just hired X!") now and then. ↵

How do we TEACH in such a setting? There has to be a strong human element. There must be dialog. Only assignments that are perfectly packaged can be run without this; and those, I agree w/ Mark, we SHOULD package perfectly. But: ↵

I am arguing that we should have as few of those as possible. (Either that, or spare me your authenticity BS when talking to me about programming languages and methods: I see it for what it really is, "I learned to code in the 80s & don't want to get outside my comfort zone".) •