Thursday, 3 November 2016

Crossing the Bridge

And having started from that left hand end of the bridge in an engineering role I have tried to explore some of the delights that await as you cross to the other side.

One of the odd pleasures of this challenge is seeing how difficult things become clear... but if anything even more delightful is to find how obvious things start to become problems.

A processor has executed an instruction. What can it do next? Just three things.

It can move on to the next instruction: and so the idea of a sequence is natural and obvious.

It can jump back to a previous instruction. And so the idea of a loop is present, but not yet obvious. We know that to jump back just anywhere is the road to madness. The jump has to be educated, trained to fit into the pattern. I write lots of flowcharts. To apply the pattern I have a rule that jumps back from the main flow must go to the right (anticlockwise) and furthermore no line is allowed to cross another.  So this is allowed:

But this is not:

Stick to the discipline and you have created the logic of the loop from the potential chaos of the jump.

And what is the other option? The processor can jump forward. Therefore it has opted to omit some part of the process, we are creating the conditional if / else construction. Here again my jumps need to submit to the discipline: all jumps down must go to the right, and no line is allowed to cross another. So this is allowed:

But not this:

This is what a proper if / else brings out in a higher level language.

And so given the sequence, the loop, and the conditional, we have the essence of structured programming. Everything we need.

What could be more obvious?

But then we start to wander across this enchanted bridge and soon we discover mysteries.

I clearly remember when I was learning Scheme, just about the first thing I wanted to write was the table of Celsius to Fahrenheit conversion from somewhere near the start of Kernighan & Ritchie. And I sat there thinking... just a minute, hold it right there, how exactly do I write a FOR loop? Surely there's got to be a way to write a FOR loop, otherwise...

Then of course you encounter the delights of looping by recursion, and the more mature delight of realising that your loops dissolve in functions that operate on collections directly, you discover MAP and FOLD and FILTER and so on. So the loop, which seemed so obviously essential to programming, becomes a stage that you leave behind. Odd. Disturbing and yet illuminating.

How truly it is written, In the search of the Way, every day something is left behind (Tao Te Ching Ch.48)

Next you discover pattern matching and see how a function can fork according to the structure of its arguments and you start to realise that you can make conditions without going through IF... in fact do you need IF at all? Can all your decisions be made on the basis of pattern matching with the odd guard or two here and there? Does IF go in the bin next to LOOP?

Then the final stage of your enlightenment comes when you discover that the sequence has now... gone. That most obvious thing of all, the increment of the program counter, becomes a problem that the Masters have to invoke arcane spells from mathematics to solve.

It turns out that even

is no longer allowed...

No comments:

Post a Comment