Friday, December 02, 2005

Why my walls no longer topple

If you zoom right out past design and architecture and specification and business case ... a program looks like the phone system.

If you zoom right in on the code it looks more like lego blocks: code is not so much written as it is assembled, coders constantly re-use the same blocks over, and over again.

These blocks are used in various sizes and have been called different names:
But for here they are just blocks.

The blocks have a layout of slots into which other blocks' pegs may fit. So a machine to search for one apple in a barrel might be built by
  1. using a standard layout like "Linear Search"
  2. filling the slots of that layout with blocks called "array", "for loop", and "index"
  3. turning on the motors, and
  4. seeing if the right apple falls out of the barrel

Any one of the blocks may be built on as needed. For example
  • one number might not be enough to remember our place in a barrel of apples, so we might use (X,Y,Z) co-ordinates instead of an index
  • apples are in layers in the barrel so we might use multi-dimensional arrays
  • apples might be described by variety, colour, smell, ...
We may need to change the layout we are built on as well,
  • if all the red apples are at the top changing gradually to green at the bottom we might be able to use a Binary search
  • if someone suggests searching by smell we might invent a new search (and patent it quick)
And just when this moving, interconnected, brittle model is reaching room size, it is either so bad as to need major overhaul, or so good as to need some extra features. Hence good code is like good Science - it remains a temporary hypothesis of what is required, always waiting for better requirements or better testing.

The reason source code can remain so flexible is because of the blocks: each has a specific layout of slots. Each slot holds one block and there are are only a few slot shapes. Object Orientated Programming allows coders to shape new slots, Language Oriented Programming allows them to lay out their own pattern of slots in a block, but the popular programming languages have remained notably conservative in how few blocks they provide. The trend in languages is now to reduce the range of block and slot shapes from that offered by, say, C++.

OOP does allow me to define my own blocks, but it can still be too much effort to get the blocks I've made to fit the available slots. If it looks like it might take more than 5 lines of "block whittling" I'll abandon the effort, and wright out my 5 lines of search code from first year one more time, because the fewer layouts to remember the better.

My poor wee brain capacity prefers fewer layouts, and those which are "as simple as possible, and no simpler". My first Lego walls all toppled over, till I learnt how to overlap the bricks, and overlapping around corners ended the topple altogether. Similarly with my coding - once I know a particular layout of blocks is solid I will be more likely to try it next time the problem looks similar. (Hypothesis: older coders should use sounder algorithms, because they have kept "upgrading" their default algorithm every time they found a context where the old one failed in some way.)

When there is no other good reason to reduce the range of choices when block-building, we just adopt conventions to do the simplification: There is no real rationale for using while loops when searching files, and for loops when searching arrays, it is just that that's how everyone else does it. It is easier to read (and write) code when there are fewer kinds of block layouts to worry about.

It has been said that there is no problem programmers won't try to solve by adding another layer of abstraction. And this is often because they are seeking a layer where they can use simpler block-layouts. Being able to build your blocks in a simple enough way (so simple that you know it will work), is often the indication that enough abstraction has been done.

If Intelligence can be defined in a soundbite then it is "making good choices", and the harder the choices are to make the more intelligence is needed. One sign of coders' intelligence is the way they reduce the explosive range of what can be written to the just those few block layouts needed for a phone system.











--------
"Style solicitor": A kind of language lawyer who does not have a standard to back them up.

0 Comments:

Post a Comment

<< Home