LOGO Manual (1974) [pdf]
dspace.mit.edu
dspace.mit.edu
LOGO's great. It was my first introduction to programming back in 3rd grade in the 80s and definitely helped shape my eventual arc as a programmer. And honestly, it's just lots of fun to play with and explore.
It is quite long, well written and shares some personal anecdotes, so I really recommend it for anyone interested in the history of the language and its influence.
Hofstadter is probably a good adjunct to any discussion re: LOGO. You could easily believe "Hofstadter's Butterfly" is just a random work of modernist art if you didn't know the science behind it. Pretty much the same with a lot of Artemis Papert's turtle art.
I bemoan the loss of fractal composition and turtle graphics as a mainstream educational thread. Both embody clear visual consequences of repeated application of procedural thinking. We used to train kids that certain types of art can be linked to procedural thinking, where the abstractions involved were much more on the mathematical side. Now we just tell them "download this python package and these 3d model assets" where the abstractions are muddied and focused on tools rather than the thing the tool makes. We're lucky if kids walk away understanding 3d cartesian space.
But I digress...
LOGO MANUAL
by
Hal Abelson
Nat Goodman
Lee Rudolph
It reminds me, one of the earliest software I wrote was a kind of mini-LOGO that controlled (via RS232 connection) a robot turtle that a friend built, in high school. I suppose that was in the 1990s, and if I remember correctly I wrote it in Turbo C, around when OOP and C++ were starting to get popular (?). And the funny thing is, a big part of my work these days is developing a domain-specific language, not too different from LOGO or BASIC, designed for end-user programming.
There were motors, lights, and sensors you could program. One project I remember was build a car with a light sensor on the front, and then write a control loop that uses the sensor to make the car follow a line on the floor.
Here’s a blog post about someone exploring the tech:
http://lukazi.blogspot.com/2014/07/lego-legos-first-programm...
> 14. MUSIC BOX
> LOGO has primitives which supply output for the music box. A LOGO user can specify parts for up to 4 simultaneous voices, each voice having a range of five chromatic octaves. In order to avoid timing problems the music is compiled into temporary storage and then output to the box at a constant rate, rather than played in "real time".
> The music system has been designed with specific uses in mind. (See, e.g., the papers of Jeanne Bamberger.)
Following this name, I found:
> Bamberger was appointed at the Massachusetts Institute of Technology from 1970 to 2001, where she taught in the Music and Theater Arts Section. At MIT, she attended a day-long seminar in April 1970 organized by Marvin Minsky and Seymour Papert, then co-directors of MIT’s Artificial Intelligence Lab, on "Teaching Children Thinking".
> Learning about Papert's development of Logo and Minsky’s digital music box, Bamberger was inspired to embark on a career combining music, computers, developmental psychology, and education to change how music was taught.
Schools should teach LOGO to grade schoolers. Two birds with one stone. Learn something about computers and learn how to use a keyboard.
I remember I was particularly proud of drawing a simple house with an animated dashed border. Since we did not have hard disks yet and floppy disks were very limited in number, our computer teacher helped with quickly transcribing the code from screen onto a paper, so that we don't lose the program I had just written and demonstrated to others.
I have written a blog post about my happy little experience with Logo programming, in case anyone wants to read more about it: https://susam.net/blog/fd-100.html
I'm reminded that when I was taught LOGO in the 70s it was in a class where there was about a 3 to 1 student to teacher ratio and the lessons were far from self-paced. Maybe THAT'S why I have such great memories. It's 'cause I had someone right there to answer questions. And my memories of learning LOGO in the 70s was it was very much like an American Montessori experience. The "teacher" introduced a concept and you got to play around with it for an hour. Then there would be a new concept followed by more play. And as I mentioned, if I found I couldn't do something I wanted to do, the teacher was right there.
For my side I did learn LOGO first in school. My son and daughter, I see they're being told Scratch.
Why? Simple, they're learning on iPads, not computers with keyboards. Scratch Jr. has an iPad app where kids can drag and drop the visual programming blocks to do stuff.
That's why they go for Scratch and not LOGO anymore. I hope they will teach them LOGO at some point or I will.
As someone who learned to program in Scratch many years ago, don't worry about it. I've written in languages from Python to Assembly, I've worked professionally as a programmer, etc. It's fine.
As far as I can tell, the best way to teach someone to program is to enable them to pursue their own projects and to help them when they get stuck before they get so frustrated they give up. (Maybe there are learning styles I'm not aware of, this is true of myself and of people I've met.) When I meet people who want to program but can't (which has happened approximately twice, one of them did come back to programming after a few years & succeeded), it seems to be because they didn't have access to sufficient support, and stupid issues (especially development environment issues) wore them down.
Scratch is a tremendous help in both respects. It comes out of the box which cool stuff to do (eg, I made dumb games and animated little movies). It's simple enough for nonprogrammer adults (like teachers) to learn and help debug.
7. On the other hand, we are about to unveil a radical unhiding: showing users the innards of expressions and procedure bodies via macros and metaprogramming. The central feature making this possible is the ability to convert back and forth between executable code (the blocks and scripts that we've always had) and syntax trees: lists of lists of the individual blocks and constant values (such as text and numbers), the building blocks of expressions and scripts. That conversion overcomes the only weakness of block languages, namely, that programs aren't data, which makes them harder to manipulate programmatically.
7½. Pedagogically, this is an extension of the self-reflection by means of non-hidden continuations, which call attention to the sequence of events in executing a script, and which we inherited from Scheme. Continuations are conceptually simple for the implementor, since they already exist in any interpreter for any language, and it's just a matter of making them visible to users. But they're not conceptually simple for users! The fact that they can be called repeatedly, and from outside of the script in which they were created, feels like magic. And it is; it's the magic of "everything first class." But the point here is that we didn't add this feature in response to a specific pedagogic need. Rather, explicit continuations help advanced programmers write advanced programs, and a few library blocks. And they're a way to plant the flag of Scheme in Snap!, which was a big part of our motivation.
I think it depends on what you're trying to teach kids. For young kids, scratch is probably a fine introduction to basic procedural coding (which is kind of funny since it's implemented in a descendant of the prototypical OO environment.) You can teach the same concepts with LOGO, and they did in the 70s. But it's a LOT easier to teach things like language processing and language concepts like recursion and evaluation with LOGO. But there's some question about whether or not kids younger than 8 or 9 can internalize these concepts. In the states we even hold off until around age 12 or 13 before introducing such things.
Snap! == Scheme ** Scratch
Snap! is a blocks based visual programming language like (and inspired by) Scratch, but with the full power of Scheme, an undiluted superset of Logo's and Scratch's capabilities, including user defined blocks, closures, and even continuations!
More about Snap!:
https://news.ycombinator.com/item?id=20309162
>One of the coolest ways to learn programming I've ever seen is the Snap! visual programming language, which is written in JavaScript and runs in the browser. https://snap.berkeley.edu
>It's the culmination of years of work by Brian Harvey and Jens Mönig and other Smalltalk and education experts. It benefits from their experience and expert understanding about constructionist education, Smalltalk, Scratch, E-Toys, Lisp, Logo, Star Logo, and many other excellent systems.
>Snap! takes the best ideas, then freshly and coherently synthesizes them into a visual programming language that kids can use, but is also satisfying to professional programmers, with all the power of Scheme (lexical closures, special forms, macros, continuations, user defined functions and control structures), but deeply integrating and leveraging the web browser and the internet (JavaScript primitives, everything is a first class object, dynamically loaded extensions, etc).
https://news.ycombinator.com/item?id=23053999
>Snap! has the full power of Scheme (first class functions, user defined blocks, recursion, closures, continuations, JavaScript integration, etc), with a visual block syntax and playful graphical environment with turtle graphics like Scratch.
>The following post is a couple years old, but maybe somebody can provide some updates and recent info!
>Edit: I should have RTFA first, which is totally up to date, just published in 2020, from the turtle's mouth:
https://escholarship.org/uc/item/1623m1p3
>Brian Harvey’s Personal Narrative on Snap!: Scheme Disguised as Scratch
>In 2009, the University of California, Berkeley, was one of several universities developing a new kind of introductory computer science course, meant for non-CS majors, to include aspects of the social implications of computing along with the programming content. Scratch wasn’t quite expressive enough to support such a course (it lacked the ability to write recursive functions), soProf. Daniel Garcia and I thought “What’s the smallest change we could make to Scratch to make it usable in our course?” After 20 years teaching Structure and Interpretation of Computer Programs [Abelson et al.1984], the best computer science text ever written, I knew that the answer to “what’s the smallest change” is generally “add lambda.” I joined forces with German programmer Jens Mönig, who had developed BYOB (Build Your Own Blocks), an extension to Scratch with custom (user-defined) blocks, including reporters and predicates. [...]
Anybody else in Barcelona for Snap!Con this week? Let's meet up and say hi!
Just kidding. But taking a random collection of APL concepts and applying them to a graphical editor probably isn't the recipe for success you may be thinking it is.
But in the tradition of the Computer Science Logo Style series (which built up to things like toy pascal compilers and expert systems), I occasionally dream of learning enough Snap! to port Iverson's samples from this lecture...
I agree with Iverson that notation is important. Just look at Maxwell's Equations. There were 26 of them until Heavyside noticed they could be put into vector form and suddenly there were 4 (5 if you squint.)
But yes, just because an approach is popular doesn't mean it's useful in all cases. Just look at Python.
I was lucky enough to be able to talk with Doug Engelbart in the 2000's. One of the points he brought up, which was elaborated in Bardini's book about him, was the source of friction between him and Larry Tessler. Engelbart liked to emphasize functionality of notation (be it textual or graphical) over ease of learning. "If it was important, the users would take the time to learn it," is a paraphrase of what I think he was saying. Even when he was at SRI (before working on the Alto) Tessler was advocating for "easier to learn" abstractions.
Where is the truth? Somewhere in the middle? Hard to say.
(where does Ableton Live fit into the metaphor above?)
Which is to say... Smalltalk benefited greatly from digesting the Scheme Papers in the 70s. It's not idiomatic to Smalltalk, but you can sort of do lambdas by defining code blocks independently of classes and applying them to objects.
Squeak really came into its own as a Smalltalk when they bolted Morphic onto it. To this day I am still hurt the JavaScript community rejected the power of prototypal inheritance and bolted Java's broken class system onto the side of the language.
Which is to say... if you look under the hood of Squeak/Scratch, you'll find LOGO's philosophic descendants. And bits of Lisp that LOGO didn't implement.
While I have never worked as a professional software developer, computers have been a hobby all my life. I don't think the fact that the language I have mostly written code in in recent years is Emacs Lisp is unrelated to the above moment.
I remember the exact moment I first discovered recursion. Some fantastic individual in our early 90's school district had arranged for LOGO clubs to be created in various schools, and even had a little competition at the end of the year.
Recursion was, apparently, the thing my team didn't know how to do to make those nested squares one of the problems required :)
Given that LOGO is a Lisp dialect, that sounds resonable.
I keep hearing about m-expressions, and think about how they're similar to the LOGO syntax (though I don't think they're exactly the same.)
Worth reading if you haven't heard about them: https://en.wikipedia.org/wiki/M-expression
Especially if your biggest critique of Lisp is "all those annoying parentheses."
Doing some programming on the side as a hobby or as an adjunct to other professional work is "on track" with what the computer science luminaries from the 70s were saying.
Though... I've often said Excel is a programming language, only that you get to program a data-flow virtual machine one cell at a time. So... I think more people are programming than know it.
I've tried Java, Python and LOGO. LOGO had by far the best results as a first programming language.
a. BASIC is a great language to introduce imperative programming. It's even better if you can teach Dartmouth BASIC, which is more feature-rich than any of the smaller BASICs that came with micros in the late 70s / early 80s. Microsoft BASIC is great if you're processing a sequence of data inputs, which sort of makes sense as this the type of "computing" people had in mind in the late-60s / early-70s. Visual BASIC came along much later and (not surprisingly) had features intended to make larger programs easier to maintain (local variable, named subroutines, etc.) though later versions of Dartmouth BASIC had similar features. We couldn't use it 'cause it was a single-source language and honestly, from a professional perspective, people were MUCH more interested in C/C++ at the time.
b. COBOL is great because it forces you to put your data structures up at the top of the program. Peter Naur has a quote "Show me your data structures and I can intuit your functions. Show me your functions and I'll spend all afternoon intuiting your data structures." And there's something to that. So sure... laugh about COBOL all you want, but from a pedagogical perspective, it had several advantages.
c. C/C++ benefited from the "I want to learn a language that will lead to a better job" syndrome in the 90s. If you picked up a copy of Dr. Dobbs in 1992, it was all about C++. My personal opinion is C++ is only now starting to be ready for prime time with recent language changes. It's hard to teach. It's hard-ish to learn. It's hard to debug unless you have the specifics of core concepts down (similar to JavaScript). I taught an intro course in C/C++ and counted it a victory if I got students to the point that they understood how stack frames were related to function calls and where static, global and local variables were allocated from.
d. I love Lisp because it was effectively my first language. There's a lot to digest with Lisp. It's as hard as C++ to teach, but for different reasons. There area lot of concepts you have to master to get good at it: recursion, macros, what the heck it means to evaluate something, what that single quote thing means. And it's far from obvious why you're doing what you're doing. I think you have to show learners A LOT of idiomatic Lisp code to get them to understand how the code maps over to language concepts. Or at least that's how I did it. Introduce a concept, then some code demonstrating the concept, then some code demonstrating the concept and how it relates to other concepts introduced previously. The thing I like about Lisp is it seems to have fewer, but more powerful high-level abstractions. And I think as an industry we could do a LOT better at tailoring courses on analysis and design for non-OO or non-imperative environments.
Anyway... just my $0.02.
Modern update:
- Show me your functions with pattern matching, and I can understand your functions and intuit your data structures, even if they are written down somewhere.
Programming is (my definition, everyone has a different one) breaking down problems in different layers until you know how to write that as code and then abstracting up.
E.g. in LOGO:
Drawing a house breaks down to: draw the rectangle for the building, draw the rectangle for the door, draw the triangle for the roof.
The abstracting up: Write a procedure that can draw triangles and rectangles and replace the code with that.
It's not learning syntax, but programming. I wrote code in 30+ languages and was paid for code in 20+ languages, I think it is more imporant to understand programming than language syntax, which is easy to pick up.
(As a counter example to myself, I've learned programming with VIC-20 BASIC)
Turtle graphics just makes the entry to understanding what programming is much easier.
https://www.donhopkins.com/home/code/llogo.lisp.txt
When I was 17, Terrapin published my first commercial code on their C64 Logo utilities disk: a Logo Adventure program, a simple non-graphical game that showed off Logo’s list processing and functional programming capabilities.
https://donhopkins.medium.com/logo-adventure-for-c64-terrapi...
Lars Brinkhoff got some of this code to run in MacLisp on an emulator! (I don't know how much of the historical hardware the emulator supports yet, but he's probably worked on some of that too. ;) )
https://github.com/PDP-10/its/issues/620
Thanks to Lars, here are two revisions of an AI Lab memo about LLOGO:
http://bitsavers.org/pdf/mit/ai/aim/AIM-307.pdf
http://bitsavers.org/pdf/mit/ai/aim/AIM-307a.pdf
And a Logo manual and glossary of PDP-11 Logo:
http://bitsavers.org/pdf/mit/ai/aim/AIM-313.pdf
While I was lucky to see LOGO as a child, I completely missed out on the robot phase of the language, which I think was what Seymore Papert was most interested in. (Though I did get to play with a graphical turtle with TI Logo in the very early 80s.)
I re-read Mindstorms a few years ago and I have to think Papert must have thought turtle graphics were a half-measure. A __LOT__ of what he talked about was how children "embody" abstractions to learn how the world works. Somewhere out there I saw a video of kids in the UK who, without a computer, were taking turns being the turtle while other kids recited program instructions to the "turtle." I think the implication was that it embodied many of his research objectives, even thought there was no computer (other than the kids) present.
Such a pity that today we don't see LOGO in elementary and high schools. I remember having used it quite a lot when I was a kid. The LOGO that I used at home was one that had a demo of a "dancing chair", you would see a chair appear and disappear in a rotating fashion around a circle, but I can't recall its name nor find it online when I searched for it.
i could see assigning a naughty website to that key being a thing in another timeline..
https://donhopkins.com/home/TurtlesAndDefense.pdf
TURTLES AND DEFENSE
The following letter, which was the response to a request for information about the use of AI hardware for defense purposes, arrived through the ARPAnet after passing through many different sites (more than 4). We received permission from the authors to include it in the newsletter. They said that the time (3:05 AM) was the actual time the letter was written - Ed.
3:05am Tuesday, 19 January 1982
William Schubert
Center for Defense Analysis
SRI International
333 Ravenswood Avenue
Menlo Park, CA 94025
Dear sir:
We must admit to some initial puzzlement at receipt of your
communique of 6 January regarding possible applications of our
robotics and artificial intelligence products to military functions.
However, always eager to contribute to the defense of our
country from the ever-present threat, we put our best minds right
to work on the problem and put together the enclosed report. We
hope it will aid in your analysis.
Please note that the information we are providing is to be
used only in your analytical studies, and is not to be considered an
official offer by Terrapin to supply the systems at the quoted prices.
Please call us at (617) 492-8816 if you have any questions.
Sincerely yours,
Patrick G. Sobalvarro
Leigh L. Klotz
Senior Software Engineers
Terrapin, Inc.
Introduction
At Terrapin, we feel that our two main products, the Terrapin
Turtle®, and the Terrapin Logo Language for the Apple II, bring
together the fields of robotics and AI to provide hours of
entertainment for the whole family. We are sure that an
enlightened application of our products can uniquely impact the
electronic battlefield of the future.
The Terrapin Turtle® is a small, versatile robot that can
perform any number of complex tasks under computer control. A
powerful A1 programming language is necessary to realize the full
potential of this advanced device.
The Terrapin Logo Language, developed at the Massachusetts
Institute of Technology Artificial Intelligence Laboratory's Logo
Group, is ideal for this application. The Logo language is a close
relative of Lisp, the language used most widely in AI research. It
fills the bill quite handily!
Descriptive Information
[...]
Munitions
The Terrapin Turtle® does not currently incorporate any
munitions, but even civilian versions have a downward-defense
capability. The Turtle can be programmed to attempt to run over
enemy forces on recognizing them, and by raising and lowering its
pen at about 10 cycles per second, puncture them to death.
Turtles can easily be programmed to push objects in a
preferred direction. Given this capability, one can easily envision a
Turtle discreetly nudging a hand grenade into an enemy camp, and
then accelerating quickly away. With the development of ever
smaller fission devices, it does not seem unlikely that the Turtle
could be used for delivery of tactical nuclear weapons.
[...]https://www.youtube.com/watch?v=-V_OPfmbbCk
https://www.youtube.com/watch?v=fTO-Ruby-Uo
https://www.youtube.com/watch?v=CJlRGe5QGhs
Also thanks to Lars Brinkhoff's research: Here's a video uploaded by Cynthia Solomon. Seems legit.
https://www.youtube.com/watch?v=c4kMzrDr4jQ
Definitely check out the rest of Cynthia Solomon's youtube video treasure trove, with lots of great stuff by Marvin and Margaret Minsky, Seymour Papert, and others from MIT and Atari Cambridge Research:
https://www.youtube.com/user/cynthiaso/videos
Seymour Papert on Logo, Turtles and Giraffes:
https://www.youtube.com/watch?v=maDzjHIiXZc
https://www.youtube.com/watch?v=lDyym_9-E-g
https://www.youtube.com/watch?v=ha8sTgtUejM
A gestural programming system developed by Margaret Minsky, Danny Hillis, Daniel Huttenlocher, David Wallace (Gumby), and Radia Perlman at the MIT-AI Lab:
https://www.youtube.com/watch?v=-Wq6SQTVM9M
Marvin Minsky demonstrating a Logo Machine with an acoustic modem and cassette tape, talking about education theory, and showing a part of his first "thinking" machine: a simulated nerve synapse (1 of 40) with an adjustable knob that he built in 1951 out of WW-II surplus hardware, and discussing playing with Tinker Toys as a child:
https://www.youtube.com/watch?v=c4kMzrDr4jQ
https://www.youtube.com/watch?v=S72xF3gd-mI
https://www.youtube.com/watch?v=yZRQQl8mA0c
https://www.youtube.com/watch?v=dfKRNHRyD64
David Levitt demonstrating his musical improvisation software: