ACCU Home page ACCU Conference Page ACCU 2017 Conference Registration Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

pinEditorial: Learning Fantasy Languages

Overload Journal #116 - August 2013 + Journal Editorial   Author: Frances Buontempo
The last Overload editorial described a Fantasy Language. Now, how do you learn one?

I would like to thank Ric Parkin for stepping in and writing an editorial for the previous Overload. His presentation of a fantasy language (FL) got me thinking, thereby stopping me from getting round to writing an editorial yet again. How would I learn FL? I would not be able to search stack overflow [SO] for answers. Perhaps this is a good thing. I would not be able to buy any books on the subject. This may or may not be a good thing. Books are frequently time consuming and, as previously discussed, heavy [Overload 111]. I have not bought any books so far this year, provided that comics, a book for completing a survey, my Dad buying the 4th edition of The C++ Programming Language [C++PL] for the latest ACCU study group and somehow ending up with a book after going near the charity book stool at this year’s ACCU conference do not count. Similarly, any books in the form of PDFs that have ended up on my Kindle do not count. So, how would I learn FL? In this extreme example, I would have to implement it myself in order to learn it. I did start learning C++ by writing a parser for C++, which appears to be unconventional. To be fair, it just parsed C with classes to expose constructors and public functions to a rapid application development tool. Nonetheless, this was a good way to start learning a language. It certainly made using it seem a doddle by comparison. Before progressing on to using the Standard Template Library, I was encouraged to write several container classes myself to get a solid grounding in how they might work and what sort of interface they should provide. Though it may have been quicker to just use the tools that already existed, rather than re-invent the wheel, I appreciated the chance to think deeply about what is going on under the hood.

Since my book ban, I have been trying to read some of the un-read books I own. My dream is to buy more when I have caught up. I am making some progress. I have eleven books on the go at the moment, and have just finished The Structure and Interpretation of Computer Programs [SICP]. The latter part of the book considers various approaches to implementing lisp, which makes the reader think deeply about how a programming language works. It poses a variety of problems ranging from considering the effect of trying various orders of evaluation of expressions, through to lazy evaluation with streams, non-deterministic programming, creating register machines, writing a debugger, implementing garbage collection and considering what tail recursion means. Many of these are complicated ideas that someone who just programs for a day job would never really have to know about. Again we have an example of a deep – dive into a topic to learn it, which while not being strictly needed, can help with a rigorous understanding of the subject. Richard Feynman apparently once said “What I cannot create I do not understand.” There is clearly merit in learning how to write a lisp evaluator in lisp. Or working on a C++ compiler. Or joining the standards committee.

If the final step in learning FL, or indeed any language, is to implement it, what are the first steps? There may be some overlap with how humans learn anything. I was introduced to Piaget’s theory of cognitive development [Piaget] at teacher training college. At the time, I failed to realise that his ideas are about how small children learn while they grow up, rather than how adults learn. Nonetheless, some of the stages and processes still possibly happen in adults. He talks about assimilating or taking on board new information and how this gets accommodated into our current world view. The accommodation step may shift our perspective slightly. If a person is learning a programming language from scratch the problems encountered will differ from those of another who is learning a second language. I keep writing

  for ( auto & item in stuff ) { …}

in C++11, since I know python. A person who is new to programming is likely to get the ":" instead of "in".1

Aside from the syntax differences, idioms differ between languages. Can you tell if someone knows functional programming and tries to use it in another language? Quite probably. Piaget describes other stages, such as a sensorimotor stage, from birth until the age of two, which may not be relevant to learning programming, apart from the discussions about hand-eye coordination which may relate to typing, which we touched on in a previous Overload [Overload 114]. In conjunction with the various stages through life, he identifies various processes that occur. These include conversation, decentering (shifting your perspective to view something from various angles), reversibility (breaking something to piece it back together), serriation (sorting by characteristics), transitivity, classification, elimination of egocentrism (seeing things from another’s perspective), inductive logic, testing for concrete operations (talking to others about ideas) and finally at the formal operational stage ideas are abstracted and deductive reasoning can happen. Sketching over the details, the high level view I was given at college was that pupils learn by reading, writing, talking then doing or possibly being able to explain to a peer. A similar path may happen as you learn a programming language.

You will almost certainly read code in a language you are trying to learn before trying to write any, FL excepted since it doesn’t exist yet. This provides a unique problem for language innovators. Having read some code you will eventually start trying to write some code. If you wish to continue learning the language you will need to start talking about it to others, maybe describing what you have done, perhaps via some tests, possibly getting a code review, or possibly even writing an article about it. The next step would be mentoring someone, thereby forcing you to clearly communicate what you have understood. This will probably require an ‘elimination of egocentrism’ touched on earlier. It is frequently never enough to just state how something is and expect another to repeat it back parrot fashion – there needs to be engagement and you need to understand the mentee’s perspective. Just repeating the same words over and over when trying to teach someone a new idea will almost never help. Understanding someone else’s confusion makes you understand more deeply yourself. When teaching someone it is all too easy to just give rules to follow, maybe by giving hard and fast coding standard to adhere to, or by insisting on a ‘rigid agile’ processes. As we know, Captain Hector Barbossa said, “The code is more what you’d call guidelines than actual rules.” Scott Meyers frequently gives his advice in the form of guidelines, for example “Prefer const and inline to #define.” [EC++]

I find this way of presenting wisdom and understanding beautiful. Most people are rebels at heart and will follow the letter of the law rather than its spirit. If you can give guidelines that encourage people to code with their brains engaged you are doing well.

The last step which Piaget omitted is to explain all this to a computer. Even when you think you understand an algorithm, or what your customers want, coding it up frequently throws up issues you did not initially spot. Like writing a recipe, you need to be precise and explicit in all the steps.

Science is knowledge which we understand so well
that we can teach it to a computer;
and if we don’t fully understand something,
it is an art to deal with it.

~ [Knuth]

Clearly, if I can write a C++ compiler, debugger, refactoring tool, and present proposals to the standards committee, I probably have a deep knowledge and understanding of C++. Knowledge covers rattling off edge cases, or shouting out “20.3.2” to someone speaking at the ACCU conference (you know who you are). Understanding is a different matter. ‘Understand’ is a strange word. The internet suggests its etymology is related to ‘stand’ together with ‘under’ though more with a sense of ‘inter’, ‘between’ or ‘among’, giving a hint of Greek ‘entera’ or intestines [etymonline]. If I understand something, I am right in its guts. I stand within it. I can see the world from a new perspective. The word ‘understand’ also carries flavours of investigations and beginnings. Understanding is the beginning. What is it the beginning of? It can be a step towards wisdom. Though wisdom is about knowing, it does not mean being able to rattle of a list of facts parrot fashion. Though wisdom might involve understanding, it digs deeper. “A wise man has no extensive knowledge; He who has extensive knowledge is not a wise man.” [Lao-tzu] In words reminiscent of Fight Club, the Bible tells us, “The beginning of wisdom is this: Get wisdom. Though it cost all you have, get understanding.” [Proverbs 4: 7]

Having said all this, is understanding really important? When people started a quest for artificial intelligence their aim was to create computers that mimic the way humans did things, hoping to make machines that could think. Leaving aside the question of what think actually means, this has raised several further points. Most of us are aware of the Turing test, where a human tries to decide if they are communicating with a human or a machine [Turing]. This was introduced as a way of deciding if machines can think, without having to define ‘think’. It has also spawned excellent science fiction stories. John Searle suggested if a machine could not be disambiguated from a human in this test, it could not really be seen as thinking. He introduced a thought experiment called the Chinese Room argument [Chinese room].He imagines being locked in a room and given paper with Chinese symbols on. Since he doesn’t understand these, they just looks like meaningless squiggles. Helpfully, he is also given precise instructions in English of how to respond to the Chinese, which can be regarded as a program. People outside the room pass him questions in Chinese, and by following the instructions he manages to answer the questions by writing appropriate squiggles. This may well give the appearance of understanding Chinese to those outside the room who receive his written answers, though it is clear to us he does not. If I do not understand Ric’s FL, but can program in it, does this matter? I would like to suggest it does. I will miss opportunities to improve the language and design my own. I will probably never be able to develop wisdom while using the language, guiding me to a stage of unconscious competence, where I can seemingly use the language with no thought, or at least effort, at all [Stages of competence] and I suspect I will not be able to explain it well to others.

Thanks again to Ric for stepping in last time. I am sorry this has distracted me from writing an editorial yet again. I did consider implementing FL, but have been so busy avoiding writing an editorial I didn’t have time to do that either. It remains to be seen what excuses I can come out with for next time.


[C++PL] The C++ Programming Language, Bjarne Stroustrup, Addison Wesley 2013

[Chinese room] Searle, John. R. (1980) ‘Minds, brains, and programs’, Behavioral and Brain Sciences 3 (3): 417-457

[EC++] Scott Meyers Effective C++: 50 Specific Ways to Improve Your Programs and Designs (Addison-Wesley Professional Computing Series) 2nd Edition 1997



[Lao-tzu] Tao te Ching, c.550 B.C.E.

[Overload 111] Overload 111, October 2012

[Overload 114] Overload 114, April 2013


[Proverbs 4: 7] New International Version



[Stages of competence]


  1. Many thanks to Jon Wakely for helpfully suggesting I #define in :, though I suspect that could cause other problems.

Overload Journal #116 - August 2013 + Journal Editorial