(This post has nothing to do with the Motorola 6809 microprocessor and everything to do with how inspiration sometimes comes from the strangest places.)

I spotted the aforementioned book* on a colleague’s bookshelf.  I picked it up and leafed through, quickly finding the authors’ description of programming.

What is Programming?

Given a problem, one normally tries to devise a solution.  This solution, expressed as a step-by-step procedure, is called an algorithm.  An algorithm may be expressed in any language or symbolism, and it must terminate in a finite number of steps.  Here is a simple example of an algorithm:

1. insert key in the keyhole

2. turn key one full turn to the left

3. seize doorknob

4. turn doorknob left and push the door

At this point, if he algorithm is correct for the type of lock involved, the door will open.

Once a solution to a problem has been expressed in the form of an algorithm, the alogrithm can then be executed by a computer.  Unfortunately, it is now a well-established fact that computers cannot understand or execute ordinary spoken English or any other human language.  The reason for this lies in the syntatic ambiguities of all common human languages.  Only a well-defined subset of a natural language, called a programming language, can be “understood” by a computer.

(Zaks and Labiak, 1982, pp. 1 – 2)

On reading this passage my mind immediately jumped to thoughts of a certain specification (naming no names) and the inherent difficulties in trying to capture any “real world” process or experience in a machine readable artefact.

With a mass produced microprocessor there is a high level of certainty and consistency.  The processor has a limited instruction set to work with and to program for.  Hardware failures or manufacturing defects aside, two identical processors should execute a well-formed piece of code in the same way and produce an identical outcome.  This encourages a functional approach.   Given a problem, one normally tries to devise a solution.  When the end is a computer program then a logical and systematic approach is a feasible means.

But even with the fairly simple real world problem of opening a lock introduced by Zaks and Labiak there is room for ambiguity and interpretation.  At this point, if he algorithm is correct for the type of lock involved, the door will open.  With this sentence Zaks and Labiak acknowledge the importance of context.  Not all locks are the same.  Not all locks have keys.  Not all doors have locks.  Or door knobs.  Or this.  Or the other.  There is considerable scope for the algorithm to be incorrect because of the complexity involved.  Even the seemingly simple instruction to turn key one full turn to the left might succeed or fail depending on which side of the door the user is stood.  The same lock, the same key, but a different outcome from turning the key in a certain direction depending on the user’s perspective.

Turning up the complexity dial to at least 11, consider now the challenge of capturing a teaching and learning experience in a machine readable format.  Only a well-defined subset of a natural language, called a programming language, can be “understood” by a computer.  Except that now the ability of the computer to be able to process the syntax of the programming language is only an intermediate step.  The final outcome is that other human beings must be able to replay the experience using the computer as a broker between them and the humans who experienced, or at least designed it, in the first place.  There is so much complexity that it cannot possibly all be captured.  Only by stripping away the complexity and retaining the simplest set of building blocks can the process be captured.

The emphasis is on capturing the process and not the experience.  By doing this the efficacy of the computer language can be tested and measured.  The authors of the language are empowered to proclaim that their language can be used to capture and replay any kind of educational experience.  Even, they claim, those based on as yet unknown approaches to education.  “Eureka!  We’ve solved the education problem!”  One size fits all.

It works, at least as far as “passing the test” of capturing workflow goes, only because so much has been removed.  The subtleties of the experience, such as the vital interactions between teacher and pupil amongst many others, have no place in this computer language.  The human context, beyond the process of who is working together and which resources they need to use, is lost.  As a result, regardless of how consistent and efficient the experience might be, the humans who are asked to use this now sterile environment cannot identify with it.

——–

* Zaks, Rodnay and Labiak, William (1982) Programming the 6809. SYBEX Inc.