If you are not interested in the mind or in programming, then click here right now as the rest of this article will not be your cup of tea.
Well, you're still here?
How well a computer works depends both on:
A: Yes, and it has been done. The art of mindware has been developed, but much of it has been lost again.
In medieval times the art of mnemonics was vastly more refined than it is today. There are books available nowadays that teach memory tricks so that you need never again have difficulty recalling someone's name - but the ancient art of memory was on a grander scale - it was a complex and integrated system.
In medieval times an entire speech might be remembered by relating stages in it to rooms within a building. The speech became a walk from one place to another. This memory skill was also tied to an art of oratory which in turn - and this is of crucial importance - built in structure concerning progression of ideas.
Writing has become a substitution for memory skills. It has also led to a loss of the 'oral tradition'. But the loss is greater, because the loss is not just of memory skills but also of thought patterns.
Maybe I am overstating the sophistication of the medieval skills. Possibly so. Without question though the medieval mnemonic skills show that 'mental software' has or had some form of reality. Is it possible now then to come up with a new "programming language" for the mind, a 'mental C++' in which we can each design more streamlined ways of thinking?
One initial reaction is that this is a scary prospect. Imagine being like a computer, running to a fixed program. It might be seen as dangerous, an affront ot our 'free will', something to be avoided. The reality is the opposite. It is the absence of a mental C++ that prevents us from doing our own self programming. To some extent we are trapped with the ways of thinking we have because we cannot look at them 'from outside'. We cannot easily debug our own thought processes. It would be very different if we could look at our own thought processes as easily as a programmer reads code. For this we need a language for talking about thought.
C++ would not be a good choice as a basis. The mind has a flexibility to it which doesn't fit well with the precision and rigidity of any conventional programming language. Yet computer languages offer a starting point. Memory and mnemonic technique are the mental C++ equivalent of data. Functions are the methods for recombining data, for deriving new data from old. A possible mental equivalent is the use of analogies.
We tend to use analogies in a simplified unsophisticated way. Analogies used in such a manner are rightly suspect. Because of the danger of misuse a common pattern in thinking is to discard weak analogies rapidly. An alternative is to try to find a perspective from which the analogy is strengthened, and to continue using the analogy with caution - as a tool for discovery.
Analogies are tools for discovery. The role of an analogy is to suggest questions. Few people would think that a person really does have an 'alarm bell' in their head or a C++ 'try-catch' exception handling mechanism that triggers when a suspect argument is used. The analogy does lead to questions: 'What triggers the alarm bell?' 'Can the triggers be thwarted?' 'Does the alarm bell have a battery with only so much charge?'. The more knowledge we have of the thing we are basing the analogy on the more potential it has as a powerful tool for discovery.
One way to use the 'mental C++' analogy is to list features of the C++ language and ask what, if any, equivalent there is in the mind. I'll resist this, for my interest in the analogy is not primarily to get an anatomy of thought processes, my focus is on techniques to improve thought, and this requires a different perspective.
In improving software performance, concentrating on the language features would be like an artist whose focus was on the paint and the brushes. Although one uses the language features to make changes it is experience of software optimisation itself, rather than the language, that sheds some light on how to change one's own thought patterns.
These are some suggestions from the analogy:
I could go on, possibly with more tenuous connections. However, the most useful connections are the ones one acts on, and usually these are the ones one finds for oneself.
- Programs run slow when they attempt to use more memory than is available. Arguments should be restructured so that there are "fewer balls in the air" from moment to moment.
- Two programs running at the same time on the same hardware may take more total resources than if run one after the other. Thinking about one thing whilst worrying about something else may be a waste of resources. It can be worth learning alternatives, techniques to offload or reduce strong feelings and refocus on the task at hand..
- Productive programmers debug their procedures before trying to improve performance. Their work on optimisation focuses on the most heavily used and most common cases. By analogy, if teaching ourselves how to make good and useful snap decisions, it's as well to check out the reliability of the 'slow but sure' method first.
- The kind of thinking one works to improve should be the thinking one does the most of.
- Good programs have comments. So should ways of thinking.
What of an actual mental C++, a mind language that can be written down with maybe loops, objects and memory management? Is C++ or some other computer language a suitable basis? A possibility is that one could be better off looking at how 'programs' in DNA determine the design of an organism. The 'DNA Programming language' is more about interlocking feedback systems than rigid lockstep actions - and it is a powerful language which handles a lot of complex information.