Programming Paradigms and Education: Post 1

Lately, I've been thinking a lot about how programming has some similarities to education. It may be a stretch to call instructional design a type of programming, but I do see some areas of similarity. And while students aren't programs in any way, shape, or form, most educational models rely on the idea that students will learn when instructed in particular ways. Likewise, programming presumes that some output or action will occur based on the programming code.

Specifically, I was thinking about the differences between procedural programming and object-oriented programming, and how each of these relates to education. This post will cover my thinking about procedural programming and education. The next post will discuss my thoughts on object-oriented programming and education, and the last post in the series will outline what I'm thinking about in terms of a newer model of instructional design that's related to these earlier posts. Thoughts, suggestions, and corrections are, of course, welcome.

Procedural Programming
In procedural programming, a programmer will write step-by-step instructions for a computer to execute in order to obtain a particular result. These can be in function calls or subroutines, but they are still step-by-step instructions. The program tells the computer, "First you do this, next you do this, etc., etc.," until you finally end up with the result. Wikipedia describes procedural programming as follows:

Procedural programming is sometimes used as a synonym for imperative programming (specifying the steps the program must take to reach the desired state), but can also refer ... to a programming paradigm based upon the concept of the procedure call. Procedures, also known as routines, subroutines, methods, or functions (not to be confused with mathematical functions, but similar to those used in functional programming) simply contain a series of computational steps to be carried out (http://en.wikipedia.org/wiki/Procedural_programming).

To me, procedural programming is much like the traditional model of education: students are given instructions on how to do something (e.g., solving a math problem, diagramming a sentence), and they do it. Subroutines in education include the "mini-steps" required for more complex procedures. Remember diagramming a sentence and all those little lines that came off of the phrases? Or the steps in completing a chemistry lab?

Step-by-step instruction abounds in education. First do this, next do that, etc. etc. Directions for putting together a piece of furniture and instruction regarding how to find library resources are both examples of instruction where the procedure itself is the lesson, and the outcome is that the student can "do" the procedure.

On a larger level, the class itself is like procedural programming: you start with an anticapatory set and move through the stages of teaching. Both Madeline Hunter's direct instruction model and Gagne's Events of Instruction are examples of procedural instruction models.

Unit or topic planning also involves the use of procedures. You begin with lesson objectives and move through a systematic method of developing activities that lead students toward meeting those objectives. Curriculum planning is the same. What are the outcomes of the course, and what procedures will meet those outcomes? Procedural. Like procedural programming.

In fact, instructional design itself relies on procedures. Remember the ADDIE model? Analysis, Design, Develop, Implement, Evaluate--one, two, three, four, five. Of course, ADDIE is recursive in that it's possible to revisit an earlier stage when you're later in the process, but it is rarely presented that way.

The problem with procedural education (and quite possibly procedural programming) is that it doesn't deal with complexity well. Procedural teaching is all well and good for simple concepts that really are step-by-step (like putting together the piece of furniture), but they don't work as well for real-world messiness. And it's naive of education to think that students can take procedures which have been given largely out of context and apply it to a problem where the correct action is not always so clear.

This is not to say that there is no room for this type of teaching and learning. On the contrary, Madeline Hunter, Robert Gagne, and the ADDIE model are quite useful if they are applied appropriately. The problem arises when we try to apply these models to all teaching and learning activities, or even to all instructional design procedures. We need more tools in the toolbox, which is where my thinking about object-oriented programming comes in--in the next installment.