What's Difficult in Teaching Programming

| 3 Comments

Perhaps you saw a study of the accuracy of non-programmers cargo culting the syntax of programs to write new programs. (For a good laugh, read an apologia for methodology problems in the study.)

Here's the problem with most attempts to teach non-programmers to program: programming is a creative process of solving problems, not an exercise in arranging atoms in the proper order.

It's as if we expected teach people to write great stories by giving them exhaustive grammar lessons such that they understand tense, mood (in the imperative, subjunctive, et cetera sense), and declension while neglecting study of plot, character, and theme.

Certainly we can and should discuss ways to make programming easier, to improve learning, and to prevent mistakes as far as possible, but suggesting that the primary mechanism of learning (by measuring it in apparent isolation) is mimicking syntax while ignoring the practical matter that solving a problem is the important part, while writing the program is a matter of implementation, misses the point.

A better study would have measured whether participants could describe their solution to the problem in a correct way regardless of syntax, or at least controlled away that variable.

I suspect the focus on syntax comes from the stranglehold of mathematics and computer science on programming. (In some ways, we haven't left the notation wars of Newton and Leibniz.) The irony to me is that mathematics is a world of creative problem solving.

While you can measure true differences between programming languages (at least along their theoretical axes), learning how to program at all is a skill that seems to be independent of notation. Teaching that is hard.

(I learned how to program on home computers in the early '80s, and I switched back and forth between several variants of BASIC and Logo a few times. Expressing my intention was more difficult than the particular abomination of BASIC I used. I suspect my experience is not so rare.)

3 Comments

This is why I like SICP as a programming learning book. It starts off on just the right tone, explaining the process of taking a problem and breaking it into smaller steps, with only a tiny detail about the syntax of Scheme used to express the program. A good 90% or so of the text is about the abstract ideas, not the concrete implementation of them.

I've sometimes wondered why nobody's bothered to rewrite SICP with other languages - almost any language would do and keep the structure of the text roughly the same.

I think that the hardest part of teaching non-programers is the forced reliance on linear thinking. The computer does not have a 'make it so' button that will read your thoughts, you have to think long and hard about all the steps from here to there, and then ask the computer to do them for you in a specific order. Once that is grasped, it's just a vocab issue.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on November 1, 2011 12:16 PM.

Modern Perl: The Book, 2011-2012 Edition Draft was the previous entry in this blog.

A Gentle Reminder about Test Coverage is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?