Teach two languages if you have to: Balancing ease of learning and learning objectives
June 4, 2018 at 7:00 am 9 comments
My most recent CACM Blog post addresses a common question in computer science education: Should we teach two programming languages in a course to encourage abstraction, or just one? Does it hurt students to teach two? Does it help them to learn a second language earlier? My answer (in really short form) is “Just teach one, because it takes longer to learn one than you expect. If you teach two or more, students are going to struggle to develop deep understanding.”
But if your learning objective is for students to learn two (or more languages), teach two or more languages. You’re going to have to pay the piper sometime. Delaying is better, because it’s easier and more effective to transfer deep knowledge than to try to transfer surface-level representations.
The issue is like the question of recursion-first or iterative-control-structures-first. (See this earlier blog post.) If your students don’t have to learn iterative control structures, then teach recursion-only. Recursion is easier and more flexible. But if you have to teach both, teach iteration first. Yes, iteration is hard, and learning iteration-first makes recursion harder to learn later, but if you have to do it, iteration-first is the better order.
There’s a lot we know about making computing easier to learn. But sometimes, we just can’t use it, because there are external forces that require certain learning objectives.
I correct, continue, and explore tangents on this blog post here: https://computinged.wordpress.com/2018/06/15/are-you-talking-to-me-interaction-between-teachers-and-researchers-around-evidence-truth-and-decision-making/
Entry filed under: Uncategorized. Tags: computing education research, curriculum, recursion.
Computing Ed Research - Guzdial's Take 
1.
shriramkrishnamurthi | June 4, 2018 at 7:32 am
The claim about iteration-first is based on research that does not take into account modern approaches to teaching this material (in particular, recursion: HtDP). I’d expect to see this sort of repetition of a 30-year old claim as “fact”, even in light of potentially better modern methods, in a SIGCSE paper…not here.
2.
Mark Guzdial | June 4, 2018 at 7:45 am
I’d love to see a study that uses more modern approaches to teach the material, too! I’m a post-positivist. Everything we know is valid for questioning and re-consideration. Teaching iteration and recursion is certainly still open for further study. The best evidence we have right now is iteration-before-recursion, but I’d love to see modern studies presenting better evidence.
3.
shriramkrishnamurthi | June 4, 2018 at 8:00 am
At least acknowledge that, then. Your article contains an error: the assumption that the only thing to be done is reproduce those old studies, but what’s the point, the human brain hasn’t evolved much. The fault is the assumption that that’s the only thing to be done. It’s fine if you weren’t aware of anything else that _could_ be done in this space — anything could always be revised but it’s boring to write obvious disclaimers — but you are (heck, you’re the one who kicked off the revisiting of Rainfall by bringing up HtDP, and I credit you for it every time I speak about it). When you have the pulpit and write as if this is a *settled* matter, you do a disservice to the field you’re trying to grow (and doing a great job of serving).
4.
Mark Guzdial | June 4, 2018 at 9:18 am
It’s a totally fair point. When I re-read the blog post, I agree. I described the iteration-recursion findings too strongly, as if there’s one and only one way to do it.
Can I go meta, here? I’d welcome your advice on how to manage bugs in the medium of blog posts.
You used the word “article” with respect to this post. It’s not, though. It’s a blog post. No peer review, and no editor. The value of the blog for me is that it’s a place for me to reflect on things I’m reading, to make announcements, to test out ideas. But there’s a success problem here — there’s a lot of people reading these posts, so there’s a cost when I’m disseminating my mistakes. Solutions? Well, I could make fewer mistakes. Since that won’t happen, I could be more careful, e.g., maybe add more levels of review to my posts. I do try to review posts some time after the initial writing before it gets published. But more than that would probably mean that I’d post a lot less. I do two posts a week here, and one a month at Blog@CACM. It’s a time cost, and more review would raise the cost. And a more formal review process would be less fun for me.
So, how to fix a bug once it’s found? I could edit the post, but a lot of readers get the posts via email (about 400 right now). For them, it’s a write-once medium. Revisions won’t get seen by the email subscribers.
My current solution is to identify and correct bugs just as we’re doing here — through discussion and comments. People do call me out on my errors in these comments. If someone is going to use my blog post in an argument with others, or as a prompt for later work (as with Rainfall), I expect that they’ll likely revisit the blog post (e.g., share the URL to the post), and I’d hope readers would see the commentary.
If it’s a really significant bug, like with the Stanford Java/JavaScript courses, I post a retraction, and update the blog post to point to the new article. But if I do that for every bug, I’ll never write new posts. I will continue to make mistakes.
Another solution is for more computing education blogs to be written. Then we spread the audience, and there’s an ecosystem of commentary. Maybe Guzdial’s mistakes wouldn’t be so expensive then.
5.
gasstationwithoutpumps | June 4, 2018 at 1:23 pm
I think that short follow-up posts (with a pointer in the original post) is the best way to fix blog posts. I make a lot of mistakes in my blog, because I’m exploring ideas that are new to me, so having a good follow-up method is important. Because many people read blogs by e-mail or RSS feed and don’t subscribe to the comments, a short correction post is more valuable than an extended discussion in the comments (though that is valuable to a different group of readers).
6.
Grant Hutchison | June 4, 2018 at 8:40 am
This year I exposed students to 2 different languages (MIT App Inventor and then Processing) and I feel that there was some beneficial learning obtained by doing so. Obviously this is not scientific and they could have deepened their knowledge of the initial language (MIT App Inventor), but the exposure to an alternative style of coding for those students (majority) who will not take another CS course is a worthy learning goal.
It provided a framework to discuss connections across the 2 languages including how variables are declared and values assigned for example. Since App Inventor is an event based environment and Processing is not (at least by default it isn’t) it would be similar to the recursion vs iteration debate. I find that teaching repetition in an event-based environment is always a bit unnatural and I focus on state machines and state transititions.
7.
gflint | June 4, 2018 at 9:58 am
My teaching goal is to not have my high school students learn a programming language, but to learn how to learn a language. We will do two to three languages a semester. I have no idea what language they are going to need if they do CS in college so I want them exposed to several languages and understand how they differ and how they are the same. The first couple languages are a struggle but then they learn about APIs and learn how to Google. Knowing how to learn is so much more important that having a syntax memorized.
8.
Are you talking to me? Interaction between teachers and researchers around evidence, truth, theory, and decision-making | Computing Education Research Blog | June 15, 2018 at 1:00 am
[…] wrote a blog post earlier this month where I stated that iteration should be taught before recursion if one is trying to teach both. For […]
9.
Mark Guzdial | June 15, 2018 at 7:15 am
I correct, continue, and explore tangents on this blog post here: https://computinged.wordpress.com/2018/06/15/are-you-talking-to-me-interaction-between-teachers-and-researchers-around-evidence-truth-and-decision-making/