Category Logo History and Contemplations

Miss Johnson had been a teacher for more than 20 years. She had taught a variety of subjects to students of different ages and backgrounds, but her favorite subject to teach was computer science. She loved teaching her students about algorithms, programming languages, and how to write code. However, she had always felt that something was missing in her curriculum. She wanted to teach her students more than just how to write code, she wanted to teach them critical thinking skills.

One day, while browsing the internet, Miss Johnson came across the Logo programming language. She had heard of it before, but had never used it in her teaching. She was intrigued by the language’s simplicity and the way it encouraged students to think creatively and logically. Miss Johnson decided to do some research on the language and learn more about it.

Over the next few weeks, Miss Johnson studied the Logo programming language and created lesson plans that incorporated it into her curriculum. She was excited to introduce the language to her students and see how they would respond.

On the first day of class, Miss Johnson introduced the Logo language to her students. She showed them examples of programs that had been created using the language and explained how it worked. The students were skeptical at first, but as they began to learn more about the language, they became more and more interested.

Miss Johnson started with some simple programs, showing the students how to draw basic shapes and move a turtle around the screen. The students were amazed at how much they could create with just a few lines of code. Miss Johnson then introduced more complex programs, challenging her students to think critically and logically.

The students worked on programming exercises both in class and at home. They spent hours writing code and experimenting with different algorithms. Miss Johnson encouraged her students to think outside the box and to try new things. She was impressed by how quickly they picked up the language and how much they enjoyed programming.

As the weeks went by, Miss Johnson noticed that her students’ critical thinking skills had improved dramatically. They were able to break down complex problems and develop creative solutions. They were no longer satisfied with just finding the right answer, they wanted to understand the process behind it. They were thinking more logically and analytically, and were better able to apply their skills to other areas of their lives.

Miss Johnson was proud of her students and the progress they had made. She decided to organize a Logo programming competition for her class. The students were tasked with creating a program that would draw a picture of their choice. The winner would be chosen based on creativity, complexity, and efficiency.

The students worked tirelessly on their programs, spending countless hours perfecting their designs. Miss Johnson was impressed by the level of detail and complexity that the students had achieved. The competition was fierce, with each student showcasing their own unique style and approach to programming. In the end, a student named Tim won the competition with his incredible drawing of a landscape with mountains and trees.

Miss Johnson was thrilled with the success of the competition and the progress her students had made. She realized that the Logo programming language was not just a tool for teaching computer science, but a way to teach critical thinking skills. She continued to incorporate the language into her curriculum, challenging her students to think creatively and logically.

Introducing students to programming using Logo can be a fun and engaging experience that helps to develop critical thinking and problem-solving skills. Here are some suggestions on how a teacher can best introduce Logo to their students:

1. Start with the basics: Before diving into complex programming concepts, it is important to start with the basics. Begin by teaching students how to create basic commands, such as moving forward, turning, and drawing shapes.
2. Provide visual examples: Logo is a programming language that is designed to create graphics and images, so it can be helpful to provide visual examples of what students can create with the language. Show them some simple graphics and encourage them to think about how they could create similar designs with Logo.
3. Emphasize experimentation and creativity: One of the great things about Logo is that it encourages experimentation and creativity. Encourage your students to try out different commands and experiment with different ways of creating graphics. This will help them to develop their problem-solving skills and think creatively.
4. Encourage collaboration: Logo can be a great way to encourage collaboration in the classroom. Encourage your students to work together to create graphics and solve problems. This can help them to develop teamwork and communication skills.
5. Provide support and guidance: Learning programming can be challenging, so it is important to provide support and guidance to your students. Be available to answer questions and provide feedback on their work. Encourage them to persevere through challenges and celebrate their successes.

By following these suggestions, a teacher can create an engaging and effective learning experience for their students as they are introduced to programming using Logo.

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.

turtleSpaces isn’t just about games or 3D models, it’s also about art. Although generated by a Logo computer program, some of the visuals created by turtleSpaces can be quite striking! Combined with a digital art program such as Filter Forge, the results can be very artistic indeed.

Check out this gallery of turtle art:

Images Copyright 2021 Melody Ayres-Griffiths

This is a continuation of Past and Future Turtles: The Evolution of the Logo Programming Language (Part 1)

So, Logo was the greatest thing that had ever happened to education, and it was going to foster a bright new generation of geniuses who were going to change the world. We just had to get it out there, and Logo would do the rest.

That was the message its creators sent to the world. And people were listening. In particular, computer manufacturers. It was the early 1980s, an era where the price of a personal computer had dropped into the range of affordability for most of the Western market, with computers such as the VIC-20 and the Sinclair ZX81 costing as little as $100, and even those at the higher-end of the market falling below $1000.

Schools and homes could afford to own computers — barely. But to justify the expense, they needed a little additional something that promised a real benefit to those children that used them. And Logo made that promise: Logo would make children ‘think better’. The children that used Logo were going to build a better world.

And so, nearly every computer manufacturer commissioned their own version of Logo: Apple Logo, Atari Logo, Commodore Logo, TI Logo… the list went on. And they used their Logo to sell their computers: our Logo will teach Timmy and Janie how to think like rocket scientists! Our Logo will give your children the skills they need to become doctors and mathematicians. Just buy them a computer and Logo will do the rest. You can sleep peacefully at night knowing your children now have a bright, secure future!

The message resonated. The manufacturers sold plenty of computers! So many computers. Then the discount wars began between Atari, Commodore, Tandy, Coleco and Texas Instruments and they sold even more computers, with TI and Coleco eventually giving up and dumping their computers on the market for as little as $49.

Sadly, while the computer manufacturers did well, Logo did not. I mean, it did okay in the sales sense, but it didn’t do what it promised. There was a flaw in the Logo ethos: the idea was that if you gave children a tool, and showed them what the tool could do, their natural inquisitiveness would take hold and they would explore the potential of that tool to its limits, learning all of the concepts related to that tool along the way. Sounds great, doesn’t it?

But if they had only looked at domains outside of computer programming, they would have realized that this was a flawed premise. How many pianos and guitars languish in children’s bedrooms, having been played only once or twice? Painting sets? Meccano? Electronics kits? I could go on and on… the point of course is that the vast majority of people (not just children) don’t really do anything without an impetus to do so, an external drive. Very few of us are actually driven to create on our own.

To make matters worse, the Logo of the early 1980s did not actually have great utility. While the language was easy to learn and use, it was very resource-hungry and slow. And this meant it wasn’t useful for creating the thing those children who actually had that self-drive wanted to create: games! And so, Logo’s purpose for them was to simply demonstrate that you could make the computer do things, and once they understood that, they quickly moved on to BASIC and Assembly language, and Logo languished unused.

Logo’s lack of utility also meant there were few resources available for it, because programs that can demonstrate a programming language’s utility were an extension of that utility, which was extremely limited graphically to drawing algorithmic art and charts. While it was still very useful for text-based applications, everyone wanted graphics! Graphics were king. Sound was queen (and all most versions of Logo could do was TOOT a tone given in hertz, which made even playing Mary had a Little Lamb a tedious exercise of transcribing from a table buried in the back of a reference manual).

And so libraries and bookstores were full of books and magazines that had listings in BASIC and machine language, maybe a little Pascal and Forth and virtually no Logo. Logo what? Never heard of it! Turned out into the cold, the turtles retreated back into the schools, their quest to find a place out in the wider world a failure (they went to make it on Broadway and, as the story goes, they didn’t make it.)

But they still had education — they were well-established there, the teachers had at least been taught the basics and they were going to keep teaching it until told otherwise. Logo was there to stay.

There were two main companies that had been commissioned by the computer manufacturers to develop versions of Logo who were more than happy to continue to support Logo in the education market. The first was Logo Computer Systems Inc (LCSI), which was founded by some of the original Logo designers including Seymour Papert, and which had created Logo for the Apple II and Atari.

The second was Terrapin, which had developed versions of Logo for a number of computers including the Commodore 64. These two companies continued to develop and release new versions of Logo for subsequent computer systems, including the Macintosh and those running Microsoft Windows, adding utility as time went on to encourage Logo’s use, and emphasizing Logo’s strengths such as list manipulation.

For example, LogoWriter, released by LCSI, presented a word-processing like environment where users could use Logo to manipulate and generate text inside it, creating macros, templates and performing search-and-replace operations, amongst others. This was a moderately successful attempt to find an application for Logo that was less reliant on performance and better showcased its features.

Terrapin, meanwhile, created more accessible versions of turtle graphics for younger users. This trend continued, with Terrapin seeming to cater more for younger children, while LCSI grew with its users, working to make their offerings suitable for older students, into junior and senior high school.

From LogoWriter they went on to develop Microworlds, a Logo-based environment that leveraged the graphical user interface of the computer’s operating system while at the same time binding itself to it. However, there was never a goal of Microworlds projects ever leaving its environment — like Hypercard, what was made in Microworlds stayed in Microworlds.

Which was fine, because the purpose of Microworlds was to demonstrate the power of programming and other concepts, not to be an end unto itself. But it reinforced the notion that Logo was not a practical programming language, and outside of the education setting, Logo fell further into irrelevance, despite the fact that as computers advanced in power, it became increasingly more viable.

But thankfully, post-secondary academia would come to the rescue, realizing Logo’s potential. University of California, Berkeley lecturer Brian Harvey would spearhead development of a version of Logo first released in 1992, UCB or Berkeley Logo, which was more suited to post-secondary computer science education and featured concepts such as multi-dimensional arrays and advanced list handling functions.

As computers became capable of handling large amounts of independent turtles, those interested in real-world simulation took notice. In 1999 Northwestern University released NetLogo, designed to use Logo to model a number of phenomena in economics, physics and chemistry using turtles and ‘patches’, areas that influenced the turtles in various ways.

In 2001, MIT developed StarLogo, which took Logo and adapted it to facilitate agent-based simulations where hundreds or even thousands of turtles could interact with each other based on simple rules, allowing for the exploration of virtual ant colonies, for example.

On the other end of the education spectrum, Mitchel Resnick and others obtained a grant in 2003 to develop a new programming environment for children. They took up residence at the MIT Media Lab — the site of the development of the original Logo language — and began to develop a coding environment based on the idea of blocks — draggable representations of commands that could be snapped together, eliminating the need to remember complex syntax or rules involving hierarchy.

With Scratch, if the program could be snapped together, it would at the very least execute, although it may not do what you want. You can drag and place objects (turtles) into a starting position, building a scene and then animating it, using logic. This borrowed a lot from Microworlds, while adding the blocks element. Scratch has been very successful, becoming the defacto tool for teaching introductory coding (a new version, Scratch Jr, does away with language entirely, using pictographic blocks).

Blocks based coding became all the rage. But it created a new problem: how to transition children from blocks to text? Particularly when the complex syntax of languages like Python was the reason for the creation of blocks in the first place?

In some places, this is still Logo — LCSI and Terrapin both continue to provide versions of Logo that use text. But the numbers of schools that use them are seemingly in decline, with a continuing increasing number of schools doing their best to jump their students from Scratch to Python, with limited success, in the pervasive (and false) belief that most children can ‘only learn one text-based programming language’, as if children have never had any success learning a second spoken language, but yet the belief exists (just like some people believe COVID-19 doesn’t).

And so, Logo stands today at a crossroads. How can it overcome efforts by some parts of the Python community to dispose of it, and take its place as the first text-based language for children? How can it prove itself as a viable programming language in its own right, to overcome concerns (true or not) held by educators that it may be the only language their students are capable of learning, and beat back Python?

After all, despite Logo’s successes (and they are many, numbering into the millions at the level of individual students), Papert’s vision of it as a language with low threshold and no ceiling has not yet come to fruition. Can it with today’s technology? Or how about tomorrow’s?

To explore potential answers to these questions, come back next time for part three: Logo Moving FD

When I was a young child, one of my best friends was a turtle.

Not a real turtle, although that would have been fun, but a virtual one. My turtle lived inside of an Apple II, an early 8-bit computer, at my elementary school.

When I first met her, my turtle, she didn’t do much. She just sat there. It didn’t take long for me to realize that in order to get her to do something, I would need to prompt her. To do this, there was a literal prompt on the screen, beckoning me to type something.

?

And so I typed FORWARD, thinking that this should, obviously, move the turtle forward.

NOT ENOUGH INPUTS TO FORWARD

Undeterred, I revised my input to FORWARD 10, just picking an arbitrary number. Although I was only six years old, I deduced that FORWARD needed a quantity, quantities were numbers and well, ten was a good start.

And hooray, the turtle moved! I was in love with my turtle from that moment on. I learned that she could also move BACK, and turn LEFT and RIGHT. I didn’t know what degrees were when I first met my turtle, but by the time I finished our first session together, I did!

That afternoon in 1981, I had learned some of a programming language called Logo. The father of Logo was a mathematician and philosopher named Seymour Papert. Interested in learning how to improve mathematics education in young children, in the early 1960s, he had studied under Jean Piaget, a Swiss psychologist who championed a philosophy of learning known as constructivism.

When children are given new information, for example, that a full turn is made up of 360 degrees, they are likely to only accept that information if they already have the underlying understanding required, such as that a turn can be divided in half, quarters and so on, down to 360ths. Or even the concept of a number as high as 360 can exist in the first place.

Otherwise, they are likely to either misinterpret the new information to fit their current understanding (“I only understand numbers as high as 100, and so they must mean 100”) or will simply ignore it, with a silent internal ‘syntax error’.

This can improve if a) the teacher explains numbers up to 360, b) the teacher explains division and then finally c) the teacher explains that when you spin around, you are making a circle (hold out your arm! The point of your finger draws a circle when you spin) and if you spin around halfway, you’re moving 180 degrees and so on.

This may still not be enough. If the child fails to understand a, b and / or c, they still won’t understand it.

However, if the child is able to actively explore these concepts in an environment that has some measure of feedback, the likelihood of their gaining understanding improves. For example, if the teacher suggests they turn randomly, and the teacher tells them how far they have turned each time they do it, they will soon learn that if they turn halfway, they have turned 180 degrees. They will learn that a full turn is 360 degrees. They will understand that the next number after 100 is 101, and hence the next number after 200 is 201. And so on.

This is what Papert learned under Piaget. But obviously, while desirable it’s not practical for each child to have an adult giving them feedback on everything they do until they understand it. The world just doesn’t (and probably will never have) a 1:1 student to teacher ratio. This was a problem Piaget and Papert simply couldn’t surmount.

But in the early 1960s, a new technology was emerging, one that Papert realized could remove his roadblock – the computer.

Computers did not tire, they did not lose patience. Although at that time large and small in number, it was not hard for Papert to see the future, a future where schools were full of terminals connected to computers, one for each child, with which the students could explore ‘mathland’, a simple environment where mathematical concepts could be demonstrated through trial and error. The more input students provided, and the more output they absorbed, the sooner they would grasp concepts. Computers seemed a perfect fit for the task of educating children using constructivist principles.

In 1961, Papert had met an American, Marvin Minsky, at a conference in England. They presented papers that were surprisingly similar, and connected as a result. So, powered by his idea of using computers to teach children, in 1964, Papert went to the US, and joined Minskey’s Artificial Intelligence Group, a team of researchers at the Massachusetts Institute of Technology (MIT).

Papert was impressed with the technology-centric culture at MIT, and attitude that everyone had the potential to learn anything they wanted to, a position Papert shared. The students under Minsky and Papert had free rein to work on whatever they wanted, encouraging experimentation and the practical testing of even the most wild theories. Papert saw how his students, when encouraged, would learn great amounts of knowledge on their own, and collaborate with others to get past roadblocks they encountered in their pursuits. At MIT these students were known as ‘hackers’.

One of these hackers, Daniel Bobrow, graduated and got a job at a research and development (R&D) firm called Bolt, Beranek and Newman. In the mid-1960s they had started exploring computer technologies, and their potential. Bobrow became head of their new Artificial Intelligence group. There, he met Wally Feurzeig, who was leading BBN’s education group. The space race had encouraged the US government to find ways of improving math education in schools, and BBN was hoping to find a solution. They had already developed ‘time-sharing’ technology which allowed a mainframe computer to be used by many people at the same time, they just needed software to run on it that children could use to learn.

Bobrow brought in Papert and introduced him to Feurzeig, and the three discussed the idea of developing a computing language for children, Papert’s Mathland. Around that time, BBN had a visitor who demonstrated a new programming language called BASIC. Rather than using memory addresses, BASIC used line numbers to track execution, and named variables that transparently linked to memory addresses. These abstractions made it much easier for non-computer scientists to create computer programs.

BBN’s researchers created a version of BASIC they called Telcomp, which Feurzeig modified to include strings, and called Stringcomp. BBN trialed Stringcomp (using teletypes, typewriters connected to a remote computer) in eight elementary and junior high-school classrooms in 1966. That year, Minsky’s assistant at MIT, Cynthia Solomon, joined Feurzeig’s team at MIT.

After Papert visited these classrooms and saw the interaction between children and Stringcomp, he became convinced that BASIC was not the answer, and that a new language would need to be written, one more suited to learning.

Importantly, the new language would need to more adequately demonstrate how the computer came to its conclusions. Papert felt that due to computers’ requirements for literal instruction, children would be able to see how the computer ‘thought’ and realize that was how they themselves also thought, helping them break down problems into smaller elements the way a computer would when it solved them. Thus, the new language would serve a dual purpose, both teaching mathematics, and how mathematics are solved.

BASIC was too monolithic in its command-based structure, and those ‘smaller parts’ could not be shown to its users, happening behind the scenes and out of sight.

And so, the new language would both need to be able to accomplish what one could accomplish in BASIC, while doing so using smaller steps that could be inspected by novice programmers. But to avoid needless and redundant repetition of code, these steps would need to be able to be reused. Because of the philosophy behind it, Wally Feurzeig christened the new language ‘Logo’, derived from Logos, the greek word for ‘thought’.

Minsky, Papert and Solomon had a number of discussions about how Logo would work. Solomon had learned some of the Lisp programming language (a language where all code and data are written in the form of expressions and lists, the name Lisp short for LISt Processing) while Minsky’s assistant, and she appreciated its power for manipulating English language strings, which she recognized could be used as a method by which students could observe the effects of computer code on recognizable data, or data that they created themselves.

It also probably didn’t hurt that Lisp had been invented by the same BBN employee (and MIT alumnus) that had developed its time-sharing system. And so, it was decided that the new language would be a variant of Lisp.

However, Lisp had some drawbacks in terms of its use with younger coders. It had an extreme reliance on structure, using an intricate array of parentheses which often led to errors that were hard to resolve (leading to nicknames Lost in Stupid Brackets and Lots of Irritating Superfluous Parentheses). Its interpreter was also bulky, and not interactive, like BASIC.

In designing Logo, Papert, Minsky and Solomon took the expression, list and string elements of Lisp, removing much of the need for brackets by making assumptions about syntax parsing and inputs, and later allowing for the ‘stacking’ of what they called ‘primitives’ (functions which may or may not resolve to a value) on a single line, such that you could type:

PRINT SUM 4 4

and the computer would output 8, or:

TYPE 1 TYPE 2 TYPE 3

and the computer would output 123.

Lists allowed for the string manipulation Solomon had been hoping for:

(PRINT PICK [RED GREEN BLUE] PICK [DOG CAT BOAT])

BLUE BOAT

RED DOG

GREEN CAT

etc.

Logo was a lot more BASIC-like in its syntax and usage, while allowing for many features BASIC did not, such as the ability to create ‘procedures’, lists of primitives that could be named, and executed just like any other primitive, such as:

TO BOX

   REPEAT 4 [
      FORWARD 10
      RIGHT 90
   ] 

END

which could be executed simply by typing:

BOX

but even better:

TO POLY :SIDES :SIZE

   REPEAT :SIDES [
      FORWARD :SIZE
      RIGHT 360 / :SIDES
   ]

END

the colon indicating a variable or container for storing a value.

POLY 4 10

would re-create our box, but the user could provide any desired values, like SUM. This satisfied Papert’s need to have both the ability to demonstrate computer problem-solving in smaller chunks, while also allowing for the reuse of code. Students could create the BOX or POLY procedures themselves, then use them in other procedures. A picture would form in their minds of the hierarchy of execution, and they would understand better how the computer, and they themselves, thought.

Except that we are getting ahead of ourselves with BOX and POLY, because in the beginning Logo did not have a turtle! When Logo was initially trialled in a seventh-grade classroom (in 1968 at Muzzey Junior High School in Lexington, Massachusetts), students were using the same teletypes the Stringcomp trial had used, and they used Logo to manipulate lists and strings rather than a turtle. Which worked quite well to engage students who were strong in English, but failed to engage those who were not.

Also, on the teletype math was still just numbers, regardless of the more elegant way Logo could break down mathematical equations. Kids who didn’t ‘get’ numbers still didn’t get numbers! Papert craved some sort of graphical representation, but the technology at the time strongly precluded that. And so, towards the end of the trial, he had the idea of creating a physical robot, one that could move about on the floor, and draw out graphical representations of mathematic output.

Papert and Solomon left BBN and headed back to MIT, where they formed the Logo Group. In England, two robots had been developed that could wander about a space, their inventor dubbing them ‘tortoises’. The Logo Group developed their own robots, calling them turtles. Having access to expensive display hardware, they also developed a virtual turtle, one that lived on the computer screen.

They added primitives to Logo to control the turtle: FORWARD, BACK LEFT, RIGHT. And they discovered that Papert had been right – children took to the turtle, the turtle allowing Logo users to have a perspective inside the computer, that of the turtle, rather than depending on an understanding of abstract concepts of code paths or numbers. The procedural structure of Logo meant the turtle could be ‘taught’: taught how to draw a square, taught how to draw a polygon, creating them inside of its environment, interacting it and shaping it like a child scrawling on the wall of their bedroom.

The turtle allowed for an empathetic bond to form between it and the child, giving the child a dual sense of accomplishment when the turtle succeeded at what the child told it to do – both because the child correctly instructed the turtle, and the turtle successfully carried out those instructions, the result of the latter the evidence of the former. The child could also ‘think like the turtle’ when developing procedures and debugging, moving about the room as the turtle would, figuring out roughly what they needed the turtle to do, and then refining their program as needed.

While Logo’s string and list facilities are impressive, it is fair to say the turtle made Logo. Both the physical and virtual turtles were used by fifth graders at the Bridge School in Lexington in a trial during 1970 and 1971. But both robots and video terminals were expensive in the 1970s, and schools hadn’t widely adopted computer terminals; as such, there was no widespread use of Logo in the 1970s.

However, the emergence of the home computer market in the late 1970s provided an opportunity for Logo to reach a wider segment of the population. In 1980, Minskey, Papert, Solomon and two Canadians founded Logo Computer Systems Inc. (LCSI) and  in 1981 they published a version of Logo for the Apple II computer, which I booted up and met Seymour, Cynthia and Marvin’s turtle for the first time.

They would have been very happy I learned about degrees (and other things) from their turtle!

But where did Logo go from there? Carry on to Past and Future Turtles: Logo’s Adventures in Academia (Part 2)

And don’t forget to try our weblogo… or read the Hacker News discussion!