Why teaching programming needs an experiential approach

We have spent decades trying to teach people to program. We have tried many things from the different approaches to teaching the syntax of languages, to different, “easier” languages. It’s nonsensical to think any of it has actually worked well. The literature on teaching programming is vast and deep, and yet we are still in this quagmire. But why is this the case? it could be partially because we are too quick to jump into languages and their syntax. Are we not spending enough time teaching people about problem solving, or exploring data? Probably not. Problem solving is the crux of most algorithms. If a problem can’t be properly expressed as an algorithm it can never be implemented in any way.

Simple examples include data many people are familiar with – digital photos, taken with a mobile device. Photos are easy to take, and the data is simple enough to explore and manipulate. The exploration of data is easily achieved at the higher level by using some simple apps such as Snapseed to modify the photographs. The discussion can then morph into looking at how Snapseed modifies the “LOOKS” of an image. How do filters work? This can be used to motivate a discussion on how an algorithm can be built.

We spend far too little time teaching the things that really matter. Languages are by themselves mere tools, and only exist for the sake of coding algorithms. People can become good coders, but not true programmers because they never have a hand in developing the algorithms involved. It is akin to a HTML coder. Sure, they can code HTML, and CSS to build a website, but they may have little knowledge is the aspects of design required to build a usable, aesthetically pleasing website. The best way to teach programming is to solve problems, construct algorithms,  and introduce language constructs along the way.


When Google translate fails

There are times when I would like to use Google Translate, particularly the app, to translate something written in German, or maybe Italian. Usually it’s a recipe in a cookbook or something. Basic translations work quite well.

Here is a recipe from a old Swiss cookbook titled “Schweizer Küche”.

Here is the translation using the IOS Google Translate app.

Aargauer apple cheese salad 3-4 beautiful apples, 125 g thinly sliced ​​Emmentaler, 1 gherkin, 1 tablespoon lemon juice, pinch of ginger, salt, 2 tablespoons oil, 1 tablespoon wine vinegar, 1/2 red pepper to decorate The finely sliced ​​apples with  Drizzle the lemon juice to keep it nice white, then divide the cheese into small pieces like a thumbnail, cut the gherkin into cubes, mix with spices and marinade, leave to soak for half an hour, then arrange in portions with strips of red pepper.

Which hinestly, translated very well. Sometimes, just for fun I try and translate something like the German word Chräbeli, which is an anise cookie. The translation is of course Chräbeli, likely because it is a proper noun, i.e. a specific type of cookie. Now try Triebsalz, which is the German word for baker’s ammonia. Google translates this to mean “engines salt”, not exactly true.

A new blog!

Ramping up my work with analog/digital photography, I have decided to transition my photography and image processing work to a new blog…


It will look at the use of analog and digital photographic equipment, image processing algorithms, the human visual system, and aesthetic-based image processing. Some of the work I currently have posted here will transition across to the new blog. This blog will then be solely dedicated to programming, usability and technology related posts.


Semantics – human vs. programming languages

Semantics are about how things are interpreted.

In human language semantics, sometimes there is enough ambiguity in a phrase to allow for it to be interpreted in different ways. Consider a classic phrase like this: “The boy saw the man on the hill with a telescope.”. What does it mean to different people? Here are some options:

  • The boy saw the man. The man was on the hill. The boy was using a telescope.
  • The boy saw the man. The man was on the hill. The man had a telescope.
  • The boy saw the man, The man was on the hill. There was a telescope on the hill.
  • The boy saw the man. The boy was on the hill. The hill had a telescope.
  • The boy saw the man. The boy was on the hill. The boy saw the man using a telescope.

Five different interpretations of the same sentence. This is termed structural ambiguity, and should not  exist in programming languages. It does sometimes creep into algorithmic musings in the form of ill-conditioned condition statements. For example:

if C1 then if C2 then S1 else S2

which can be interpreted as either one of:

if E1 then begin if E2 then S1 else S2 end

if E1 then begin if E2 then S1 end else S2

This kind of logic can lead to dangling-else problems in languages such as C.

Why human brains are so great

The difference between human versus machine thinking can be illustrated aptly by our decipherment of text, and our visual interpretation capabilities. Try reading the following paragraph in which the words are jumbled up:

Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn’t mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer is at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed ervey lteter by itslef but the wrod as a wlohe.

Regardless of how mixed up words are, the human mind can still interpret them, as long as the first and last letters are in their correct places. But it isn’t just about jumbled words, it is about context, or rather predicting what comes next. Of course the amount of jumbling also has a role to play. For example HSOPIATL is easier to comprehend than say, HATOSPIL. Given the right context, it is possible to interpret the latter as well. This is what leads to being able to read a book quickly. Not every word is interpreted to the letter, so it something is miss-spelled it is inconsequential to the overall interpretation of the sentence.

So while the human mind can read a paragraph of misspelled words aloud the machine would first have to interpret them as being incorrect, find the right word, and then read it aloud. Sure it can be done algorithmically, because it is just about data processing, and speed,  but it is not as intrinsically interesting as how the mind accomplishes it.