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:
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
Any one of the blocks may be built on as needed. For example
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.
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:
- Marvin Minsky conceived frames
- the Gang Of Four wrote the book on Design Patterns,
- teachers taught algorithms courses,
- style solicitors deride them as "copy and paste programming"
- academics have published articles on clichés, frames, templates, et bloody cetera
- programming languages use keywords, operators and templates.
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
- using a standard layout like "Linear Search"
- filling the slots of that layout with blocks called "array", "for loop", and "index"
- turning on the motors, and
- 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, ...
- 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)
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