Teenage Hex

Is P = NP? Why would you ever play Twister when sober? How do you get adolescents interested in programming? This last question is a simpler and more concrete instance of the larger problem of how to get adolescents interested in anything. It is hoped that any solution to this programming challenge (P) will allow parents, teachers and society to then solve the non-programming challenge (NP).

There has been much discussion of how to get teenagers interested in tech beyond their phones. The Raspberry Pi has helped support this trend by introducing a device named after fruit, following a venerable tradition of tech targeted at children, such as Tangerine, BlackBerry and Apple.

But if the goal is programming, what should be the programming language? In the 1980s BASIC was considered the language of choice and made a strong impression on a whole generation. The home computing boom succeeded where previous initiatives, such as Teenage CICS, were felt to have corporate undertones. Edsger Dijkstra observed, however, that

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

Dijkstra’s insight does much to explain most of the code written in industry from the 1990s onwards.

These days Python is typically considered the language of choice, representing, as it does, a language that will set false expectations about what other mainstream programming languages are like in terms of feature set (orthogonal and considered), syntax (in space no one can hear you scream) and culture (humorous and surreal with a 1970s twist, washed through with British cynicism and Dutch De Stijl sensibilities). This dovetails nicely with the practice of teaching Haskell to computer science undergraduates in preparation for industry.

A more careful analysis of the target audience, however, suggests that Python may not be the most suitable choice. For example, the torpor of a typical adolescent suggests a preference for static rather than dynamic typing and lazy rather than strict evaluation.

If not Python, then what? As it’s a software problem we already have a process (indeed, many processes) for helping to determine a solution: requirements gathering and specification. As it’s a software problem, we already know that any discussion of requirements can be circumvented and left to people who failed to make the grade as programmers, washed up in dead-end jobs and made-up disciplines such as business analysis, where they are left to write stories and play cards. They can be humoured, encouraged and given the belief that their work has meaning and relevance, even when it is ultimately ignored. If there is one thing that may help to motivate adolescents into programming, it is being shown this kind of McJob. On the other hand, they may find much in common with their existing situation.

As it’s a software problem we already know the universal solution: invent another programming language. Riding on the coat-tails of a previous fad, it can be considered a domain-specific language. In this case the domain is teenagers and the co-domain is programmers.

Beyond laziness and a general lack of dynamic, what other characteristics should such a language have? Laziness suggests something functional, although it is worth noting that teens object to most things. The typical object model, however, involves classes, which is often at odds with the politics of the target demographic. Following any kind of procedure is beyond reason, so classic imperative and procedural programming is unlikely to be a wise choice. And logic programming is clearly a non-starter.

The programming style chosen should be driven primarily by arguments, which lends further support to functional programming. The language need not, however, be a pure functional language. Given that most teenagers are mixed up, it seems appropriate to reflect this confusion in the language design. It will also enable them to employ words like multi-paradigm and postmodern with greater confidence in their media studies essays.

The language should capitalise on already familiar operators and concepts, such as the Maybe and Whatever monads and the like and isKindOf comparisons. Other relational operators would include owns instead of greater than, although, because fuzzy rather than Boolean logic should be used, this is not like an exact drop-in replacement, you know, right. The use of null is discouraged in modern language design; Duh is proposed as an alternative. Teen sensitivity to anything and everything can be acknowledged by ensuring the language is case sensitive, although a compelling case can also be made for case-indifferent syntax.

What of the language’s execution model? A benefit of functional programming is the lack of side effects, so adolescents would be able to enjoy doing what they wanted without having to worry about the consequences. In contrast to many functional languages, however, a heavy reliance on exceptions is a likely need, although the exception model should be as layered as possible. Throwing up meets a common need.

Although the possibility for concurrency is intrinsic to many functional languages, it may be prudent not to include support for concurrency in a teaching language. The scheduling model favoured by most adolescents is at best frustrating, being typically pre-emptive but with long delays and without resumption of existing tasks, i.e., easily distracted. Any alternative scheduling algorithm is likely to be considered (so) unfair. Priority inversion would undoubtedly be a common problem, with things adults consider trivial taking precedence over things considered to be more important. Similarly, deadlock would hamper much progress.

In terms of development environment, an IDE would be unsuitable as there is little that is integrated about teenagers. Something that is console-based, preferably black-and-white, will most likely satisfy needs and neediness given the amount of time teenagers already spend consoling one another.

It almost goes without saying that test-driven development is completely anathema to the adolescent mindset, involving, as it does, a cautious and considered test-first approach, where desires are clearly specified in advance of their realisation. That does not, however, preclude unit testing in general. The approach most suited to teenagers is the test-after approach of plain ol’ unit testing, i.e., POUTing.

And, finally, what of the design philosophy that should be taught? This choice, at least, is simple: KISS.