Past and Future Turtles Part 3: Logo Moving Forward
Past and Future Turtles Part One
Past and Future Turtles Part Two
When Seymour Papert originally conceptualized Logo, he envisioned a language that could be used to demonstrate not just how a computer followed instructions, but how a human being followed instructions, especially those of their own making, and how they developed them. As such, the language has never been successfully optimized for computer execution, as any attempts at doing so tend to defeat the purpose of having the language be easily understandable to a lay human, both to read and write it, without complex formatting or syntax rules.
Due to these aims, Logo has historically been less a practical programming language (for production purposes) and more a vehicle for cognitive self-expression. However, the more complex that self-expression, the better for understanding how the computer — and the mind — works. And so, as computers become more powerful, the opportunities for more complex Logo programs appear — not because Logo is itself more optimal in its ability to execute code, but because the computer upon which that interpreter runs has more grunt.
To that end, games make ideal subject matter for studying not just how the computer and the coder think, but also the player. But any games we create need to meet at least a minimal standard of engagement — this is the 2020s, after all, not the 1980s. And so the slow card or word-based games of yore are not really practical in a modern educational context, not if the aim is to impress the student and so impress upon them the concepts one is trying to teach.
Because of this, 21st-century Logos have tended to stay away from complex game mechanics and instead stick to more simple concepts where perhaps an image or two is moved about the screen, there’s some simple pixel-based ‘collision detection’ and a bit of sound — enough to be mildly engaging and provide some hope the student has developed some understanding of the underlying meaning, which is generally limited to ‘do these things’ and ‘if this, then this’.
But I would argue that a reasonable understanding of logic requires more sophistication than the simple binary of ‘if A then B’ if only because these are, in the real world, almost never presented in isolation, but rather as a nested hierarchy of decision-making more akin to ‘if A then B unless C but always if also D and never if E (unless F, of course) — complex logic that tends to naturally evolve with games that themselves gradually develop their game mechanics and sophistication as they grow and become more polished.
And so, the simple ‘games’ created in platforms such as Scratch are only just scratching (pardon the pun) the surface and don’t really effect Papert’s true vision of encouraging children to develop an understanding of how to break down complex problems into considered and reasoned solutions. What we need is the ability to abstract away as much of the trappings of a complex game as possible so that we can focus mostly on the game logic and execution flow.
Luckily, with Logo’s inherent ability to preempt its own built-in primitives, we can, as Logo interpreter developers, provide a myriad variety of high and low-level tools without interfering with the coder’s freedom in creating their own procedures with whatever names they desire. Logo’s parameter processing is also flexible, meaning that square 50 and square [50] can mean and do different things. And because they’re all built-in they can all have built-in documentation that is available directly in the IDE (integrated development environment) rather than having to load a third-party library and search for documentation on the web.
Logo’s strengths make it innately suitable for the Making of Grandiose Things, given efficient interpreter optimization and sufficient compute — these ‘things’ may not be as sophisticated as those created with a low-level game-development platform such as Unity but certainly comparable to user-created games in Roblox or Minecraft, and created in a language that is much easier to read and understand. For example, the primitive nearp returns true if there are other turtles within a certain distance of the ‘calling’ turtle (the turtle executing the command.
And so, to detect if there are other turtles within 20 GL (turtle) units, all one needs to type is:
if nearp 20 [do this stuff]
and that’s it. No need to load 3D libraries or anything else. If done properly, these additional primitives add very little to the execution cost of the Logo interpreter, especially in the general scheme of things. The Oxford English Dictionary has over 170,000 words in it, the average adult knows around 30,000 of those. Learning a couple of thousand Logo primitives is not out of the question, particularly with helpers such as pop-over help.
Not to suggest that you need to learn all of these primitives right out of the gate — you absolutely don’t! You can learn a few dozen primitives and make some very complex models and artworks, just the way one always has in Logo. And the basic syntax has no need to change at all — more sophisticated syntax can be introduced as long as it doesn’t displace the traditional syntax, and there’s no reason for it to do so. But as the user gets curious, they can learn new primitives from other practical examples, and grow their own projects into other areas, creating ever-more sophisticated logic — the point of the Logo exercise.
Over time, the modern Logo interpreter developer can add primitives that can do almost anything, at any level of sophistication. For example, play a song. Or play a note. Or play a frequency. Select a different instrument. Create your own instrument. And so forth. They just need to remember to document them! And try to give them intuitive names — which can be challenging, naming things being one of the hardest parts of development ;) And as the interpreter grows, its collection of examples will similarly grow, becoming more and more impressive, and hopefully inspire a userbase.
And inspiration is the key here. The more your Logo interpreter can do, the more ways a prospective user can be inspired. And in the modern environment, if you don’t inspire the user they will move on to something that does — nobody wastes time these days on anything that doesn’t immediately enthuse them. A modern Logo interpreter needs to grab their users by their collars and drag them in, especially in education! And speaking to education, teachers are increasingly turning to Minecraft because they’ve discovered that kids are much more interested in working with something that has outside outside, more widespread acceptance than coding environments that are ‘dedicated’ to education.
Education also seems to be significantly turning towards 3D (both with coding and printing) so we’ll make that a given. It’s fair to say that 2D coding environments are niche and passe — not that they’re completely unappealing, only that the masses seem to be 3D-first, and if we want to engage as many people as possible, 3D is going to be where that’s going to happen. Also, if you can export 3D models from your Logo environment that can be printed, that’s not going to hurt. What else can we do to draw people in?
Community and collaboration capabilities are definitely near the top of the list. In an increasingly-remote world, we need to allow multiple users to work on a project together. They need to be able to interact with each other to share knowledge and insight. They need to be rewarded for their efforts both in creating projects and in helping others, perhaps with tokens they can exchange for models or music, and status. The developers will need to listen to the needs of the community (once there is a community to listen to). But their minimum standards will require a fairly advanced interpreter before one can start to draw them in.
To that end, multi-player capabilities are likely a must. The ability to store game data in the ‘cloud’ is also a given. Whatever Roblox can do we need to _almost_ do — as Logo interpreter developers, the simplicity of the Logo programming language will always be our selling point, and can make up for shortfalls in other area. But there are certainly minimum standards to which we must adhere.
And so we turn to sharing and distribution — users need to be able to share their projects, and good projects must be able to be discovered without scrolling endlessly through a generic list (something which almost nobody will do, leaving projects to languish without an audience.) Engagement must drive this, real engagement through metrics gathered by the platform, not just ‘likes’ (which can be gamed). And projects must be able to be shared on more than just the web — an ability to ‘package’ a project into a desktop or mobile app will certainly improve the desirability of the overall platform, especially if a user can distribute their game on broader app stores.
So, perhaps if we can implement all of this, Logo might be a ‘practical’ programming language after all. As we’ve seen, performance is only one small part of a very large whole. Could Logo take a noticeable or even significant share of the user-created gaming space? Perhaps. Will that result in it regaining a foothold into education and once again playing a significant part in computing curriculum?
Only time will tell, ultimately, and when it does, maybe there will be a Past and Future Turtles Part 4.