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.
Same, except they started us in 1st or 2nd grade. I (mid-40s) have vivid memories of the computer lab, with Apple computers lining either side of the wall and the lighting and everything. That segment in my early education left a bigger imprint on me than when we watched the challenger explode from the carpeted benches in my music class.
There is a fairly recent (2020) article on the history of Logo, written by Cynthia Solomon (one of the original designers of Logo), Brian Harvey (UCBLogo, Snap!) and some other people: https://dl.acm.org/doi/10.1145/3386329 (click on the PDF button to read it)
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.
I wonder if they were aware Patrick Suppes' group at Stanford was doing Logo already in the 1960s. They used Imlacs for turtle graphics, the very same Douglas Hofstadter used to edit his manuscript for "Gödel, Escher, Bach".
From what I read, Bitzer (PLATO), Papert/Solomon (LOGO) and Suppes (EPGY and Stanford) were all familiar with each other, thought each had different approaches (and if Mark Guzdial @ GIT is to believed (and he probably should be), different models for education.) I know PLATO received extensive funding from the ARMY early on while Suppe's pre-EPGY projects got more funding from the NSF. My mom's research at MIT was funded by the Air Force, but was adjacent to the LOGO team (not directly part of it.) Having talked extensively with Solomon and slightly with Suppes and Bitzer, I believe their funding sources extensively influenced the direction of their research.
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.
LOGO MANUAL
by
Hal Abelson
Nat Goodman
Lee Rudolph
As to the contents, it's impressive how advanced LOGO was for the time. In addition to controlling robot turtles, it could output to a display, plotter, and "music box".
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.
In the 1980s there was also LEGO/LOGO, a programmable interface to a line of Technic products, plus an expansion card and breakout box for the Apple II to wire it all up.
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:
That looks like a lot of fun. The green display of the Apple II brings back memories. Looking at the pictures of LEGO parts and electronics, I see that the spirit lives on this day - as I turn my head to my box of ESP32s, Raspberry Pi, and various microcontrollers, sensors, relays. It makes me realize the continuity of history, and how I've managed to play from childhood until now.
> 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.
That indeed used to happen in the 1990s and it had a big impact on my life. We used to get about 30 minutes of computer time twice a month. One of my favourite activities during that time was to try and draw interesting shapes and share the code with my teachers and friends.
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
There's a talk out there where Alan Kay talks about how they were evaluating some of the same concepts for Smalltalk that eventually went into Scheme. I think he was mostly talking about lexical scoping for code blocks. In the same talk he called Kiczales' Art of the Meta-Object Protocol the most important computer science book he's read.
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.
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.
I have mixed thoughts on this. On the one hand it feels obvious that this kind of lobotomized programming experience will be stultifying. On the other hand factorio shows what a gamified interface makes possible and I don’t see any reason it couldn’t be easily adapted for tablets.
> On the one hand it feels obvious that this kind of lobotomized programming experience will be stultifying.
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.
Snap! is like Scratch, but not at all lobotomized, with the full power of Scheme. Check out my other posting about it, and the links for lots more information.
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 part of the point jgalt212 is making is LOGO is a language while scratch is an environment. LOGO very obviously maps from sequences of lexemes to actions while that association in Scratch is a bit muddied. You can open a code browser and start typing, but the whole environment is designed to allow you to do interesting things without every typing a line of code (well... maybe a few lines of code. But a LOT fewer than with LOGO.)
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.
I learned LOGO when I was 10 or so, in mid-90s, in India. I had just learned Basic the year before, and it did useful math things, so I was not impressed by LOGO. Off course LOGO does more than what I played around with on the lab computers with (even more than Basic), in a limited amount of time.
I wonder where your lessons for BASIC and LOGO came from. I've got to think that there's a wide range of quality in lessons and lesson plans. Or at least some lessons are intended for a certain age group or emphasize one type of skill over another.
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.
I don't think I'm too far off in saying my teachers at the time probably weren't experienced with computers. I didn't have a computer at home until a couple years later (and moved to the US), and didn't really learn about data structures and algorithms until a couple more years. I can only remember doing computer labs (with ~20 shared computers, and some individual attention if you had problems) like chemistry or physics labs, with write ups and some theory. It was enough to pique my interest in computers certainly, so age appropriate lesson accomplished I think, relatively speaking.
They did for me, sort of! I was taught LOGO at like 8 years old when, once every couple weeks I think, the kids in “advanced” math or “gifted” program (latter term I only heard in 4th grade, even then it felt cheesy or worse) were bussed to a semi-school to take 2 electives at a time. I also got to take an HTML class there! This would have been approx 30 years ago.
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!
>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).
>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:
>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.
Given that the Turing Lecture ( https://dl.acm.org/ft_gateway.cfm?id=1283935&type=pdf ) didn't have any appreciable impact (in the tradition of Backus' Turing Lecture) upon either industry or academia, I doubt there any recipes for success among the masses.
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...
Now I get to flip and take the other side, implying that APL is the best language in the world:
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.
As far as somewhere in the middle goes, I guess Englebart would think the violin worth learning, while Tessler would advocate for guitars (keytars?), but neither would go so far as to perform music with a vuvuzela?
(where does Ableton Live fit into the metaphor above?)
I well remember the epiphany I felt while learning Logo in elementary school, at the moment I understood what recursion is.
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 the old days, I remember the adults all saying "Everyone will know a little programming in the future. It will be like the development of wide-spread literacy from the 17th through the 20th centuries."
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 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 :)
Yup. Lots of people forget that. They see turtle graphics and think LOGO is a toy. I learned Lisp very shortly after learning LOGO and was introduced to recursion in Lisp. It was several years before I got back to LOGO on the TI 99/4A and (of course) tried out recursion related to building adventure games. IIRC, TI Logo only allowed 4 or 5 levels of recursion (I guess it wasn't using tail recursion?).
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.)
Fascinating. Does it help their understanding of programming as much as one would hope? Offhand I imagine it would be much less transferable to their everyday work life than Java or Python. And did you try Visual Basic?
From my experience people who start with Java or Python have problems understanding programming. They learn the syntax and tools.
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)
Counterintuitive to me! I would imagine that while people might get stuck with Java syntax, Python would make it easier, and that Logo would just make it harder when they found out most languages aren't like it...
Having taught BASIC and COBOL to young adults at a trade school and C/C++ and Lisp to adults in a professional development program, my experience is:
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.
> Show me your functions and I'll spend all afternoon intuiting your data structures
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.
Show me your function bodies and conceal your types, and I shall continue to be mystified. Show me your types, and I won’t usually need your function bodies; they’ll be obvious.
I'm not sure that's true. But I'm not sure it's wrong. The only experience I really have with that is Haskell, which is a write-only programming language for other reasons.
Here is the source code to LLogo in MACLISP, which I stashed from the MIT-AI ITS system. It's a fascinating historical document, 12,480 lines of beautiful practical lisp code, defining where the rubber meets the road, with drivers for hardware like pots, plotters, robotic turtles, TV turtles, graphical displays, XGP laser printers, music devices, and lots of other interesting code and comments.
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.
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. ;) )
Although it's written "LOGO" in this seminal work, it's been "Logo" since forever. It's not an acronym of anything. It hasn't been LOGO probably since language names stopped being all caps.
The interesting bit is when I was introduced to LOGO on a spare SDS 940 in the basement, it wasn't all about moving a turtle around (I think they were still working on that bit), it was about manipulating strings. The first LOGO program I wrote constructed sentences from lists of nouns and verbs. Later when my mom taught me Lisp, we added prepositions and phrases.
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.
For the benefit of someone digging through comments in a future generation. I chatted w/ Lars via email. My memory of "doing LOGO" on a 940 comes from typing on a terminal that was sitting next to a 940. It's entirely possible the terminal was connected to another machine, and it just happened to be next to the 940. Lars suggested LOGO was actually running on a PDP-11, which is certainly within the realm of possibility. Alas, I am depending on memories from over 50 years ago, so I can't be completely sure.
Logo basically grew up on PDP-10 and PDP-11 computers at MIT. The workhorse system at the AI lab was ITS. The Logo group, which was part of the AI lab, had their own PDP-11/45 for which they created a "Small ITS" timesharing system, which was cross assembled from ITS.
LOGO can be hardcore. If you don't believe me check the Turtle Geometry book by Abelson (same Abelson that co-authored SICP). Not long ago I read Mindstorms (children, computer and powerful ideas) by Papert. Highly recommended read to anyone interested to know a bit more about LOGO, its creator and education.
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.
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.
[...]
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:
A gestural programming system developed by Margaret Minsky, Danny Hillis, Daniel Huttenlocher, David Wallace (Gumby), and Radia Perlman at the MIT-AI Lab:
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:
It is interesting as a historical document from a period of experimentation and development at MIT on Logo, and this particular implementation for the PDP/11. I find the IBM one comparatively bland as a standard reference manual from that era.
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.