Saturday, January 17, 2009

It isn't the language

A mailing list is on the edge of having the language debate again. Ironically, I'm going through old e-mail from September and this exact list had this debate then too. 

Every time we have the language debate, we get closer to the idea that the language doesn't matter, that what matters is the ideas. We want students to solve problems and we want them to understand some of the important concepts in our discipline. Thus any language should do, as long as it allows them to solve problems and understand the important concepts in our discipline.

Some languages are better choices than others. We want students to focus on the "right" problems. That is, they should spend time solving problems like "which algorithm is more efficient" or "write a program that demonstrates good use of stacks as compared to queues" and not problems like "it doesn't compile."

I think about chemistry, as I so often do in these situations. When we want students to learn about the types of reactions, we (a) teach them about the types of reactions, (b) give them examples on paper, and (c) have them do a few reactions, such as a precipitation reaction. Does it matter which precipitation reaction? No, except that we choose one that is likely to have low experimental error and high yield, since we want the focus to be on the reaction and the products, not on the error. 

I'm not going to vote, but I do think we don't need to worry about articulation or workforce readiness or how many languages students should learn. We need to focus on the important concepts and skills. If they can do it in one language, they can learn another, just like if you can do one titration you can do another - it doesn't matter very much what the specifics were since you can apply the big skills. 


  1. The hardest thing i have had to do lately is convince the Programming I teacher that a language is not the focus of programming. 90% of the time a student works on a program should be in the planning. I used to work for a programming company (not as a programmer) and this was true for the professionals. Programming teachers (especially novice ones) just love to jump into code. I am in the process of writing a non-language based Programming I (high school) curriculum. It does use a language (Small Basic) but any language will work to reach the course objectives. I am going to teach it for the first time this coming semester. I will see what happens.

  2. I hope you will post somewhere the outcome of your curriculum. I'd be very interested to learn more about it.

    One struggle I have as a teacher is with student engagement in planning. Students hate to plan. Hate. I do think planning is important and while I'm not sure 90% is the balance I'd go for, they should spend much more time planning than they want to. However, if we keep them from actually programming for too long then by the time they are finally allowed to touch the keyboard, they are bored and far less interested than they started out. It is a challenging line to make them plan while keeping their excitement up.

  3. Last summer I blogged about the teacher and the curriculum being more important than the language in use ( I really believe that to be true.

  4. You're right: The language doesn't matter. Nonetheless, it is very important which language you choose! This paradox can be explained by looking at students in the lab room.

    The thing they struggle with most often is just getting the program to compile (which is touched upon in another post here). Students tend to really have a hard time getting the syntax correct.

    If you're struggling with the syntax, you end up being confused. For example, maybe your algorithm is correct and the code is almost perfect but the compiler is still throwing a fit because you forgot a colon somewhere. Then you might think you've done it completely wrong and start to "fix" your code accordingly. It's hard to distinguish between syntactic mistakes, minor logic mistakes and fundamental problems in the algorithm. It's all a compiler/runtime error anyway.

    I'd figure that it is essential that a language is used which has a very regular syntax, and ideally an implementation of that language which has very clear error reporting. If those constraints are met, the language itself is unimportant indeed.