In this series of blogs, we have looked at how the human brain’s capabilities fail us when we try to develop computer programs using programming languages. The topics covered so far are:
- Memory sizes (Number of neurons)
- Cerebral cortex sizes (Number of neurons)
- Our brains time-slice (not multi-task)
- Examples of programming language problems
- Studies of the limits of the brain
Programming languages are not inherently evil. Nor are they pure good. The preceding blogs were written to highlight how the physical characteristics and capabilities of our brains detrimentally affect our development performance when using programming languages.
The point is not that programming languages are bad or that humans are incompetent; instead the point is that there is an impedance mismatch between human thinking and programming languages, like the proverbial square peg in a round hole.
What is really needed is a different (non-language) methodology that plays to the strengths of the human brain and minimizing it’s weaknesses. If the next big “program development technology” is programming language based, it will have about the results as previous “savior languages” and we will continue to experience the same slow and error-prone program development cycles that we have always experienced.
We Can’t Change Human Thinking
I know that there are some of you thinking, “We can’t change the way that people think, so we should just buckle down, work harder and do better.” And honestly, if that approach would work, wouldn’t it have worked by now? We’ve had some brilliant people writing programs since the dawn of computers; shouldn’t we have had some shining examples of programming perfection, of projects that are released that are 100% error free and do everything exactly the way the user wants done. Or at least projects that finished ahead of schedule and under budget?
Our mediocre past performance speaks for itself. Most development projects are overdue and undertested. Many projects are so late and so far over budget that they are canceled instead of completed. And the projects that are delivered rarely do exactly what the user wants in the way that the user wants them done. Not until version 3.1 (or later).
We Can Do Better
- When we wanted to travel faster than our legs could carry us, we domesticated horses.
- When we wanted to travel faster than horses, we invented steam locomotives and then automobiles.
- When we wanted to travel faster than automobiles, we invented airplanes to let us fly.
History is full of examples where a physical limitation of humanity has been overcome by developing new tools and technologies. The same situation exists with programming languages; we can only develop programs as quickly as our horse-and-buggy programming-language technology will allow.
What we need is the next tool, the one that removes the impedance mismatch and allows us to develop programs efficiently. The next blog sequence, Programming Languages Are Not Our Friends, will look in more detail at the problems and consequences of using programming languages.