There's a StrangeLoop talk about teaching programming by Felienne Hermans (https://www.youtube.com/watch?v=g1ib43q3uXQ) that claims that all fields have an "exploration vs instruction" debate on how to teach their field, but this debate is apparently absent from the field of programming for the most part, wherein the "mess around and figure it out" exploration style of LOGO and Papert ("every time you teach something, you deprive a [student] of the pleasure and benefit of discovery") is the predominant unquestioned wisdom. Felienne wants more pedagogy fights. It's a worthwhile talk. I love LOGO and I think our generation of programmers are very sympathetic Papert's philosophy due to most of us being self-taught to some degree (you can see the fond nostalgia already on display in the comments here), but Felienne made me think about it more critically.
Thanks for the link! It's a great discussion to have and should be a topic for all learning, not just CS Ed. If you look at the K-12 CS Ed standards defined at the state level, you'll find a generally coherent approach to staged learning of CS, both in terms of computational thinking structure (teach sequential behavior before conditional behavior) and language complexity (Scratch first, Java later). It's also worth considering playful or project-based approaches vs rigorous curricula-based learning... we're lucky to start with playfulness in CS because of the history of Logo. But what about for example, aeronautics? You might really enjoy learning to build and fly a rocket in Kerbal Space Program, but at some point you might yearn for more and benefit from a deep dive into some scaffolded traditional curricula. Then you can come back to Kerbal and apply what you learned, etc etc. Perhaps there's some sort of optimal cadence, different for each person and their interests. What's the analog for CS Ed?
I found this talk pretty interesting. Thankfully, the speaker doesn't limit the talk to "starting the debate," one of the world's annoying rhetorical tricks. She actually comes out in favor of an identifiable, different pedagogical method, and is doing research to establish whether or not it is superior.
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.
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. ;) )
Thank you for doing this, Lars, and thank you for all the amazing historical research and preservation you are doing on the PDP-10 and the origins of operating systems, Lisp, Logo, symbolic math Macsyma, and all of the software and system zeitgeist that produced Logo. We always felt like we were packaging up what our AI lab hacker culture was like, in "mind-sized bites" as Seymour said.
Thanks for the kind words! I'm grateful for the quirky, fun, and interesting work and research that was done, and glad it much of it has been preserved. (Also sad some of it has been lost.)
>Note that a good number of the programs displayed in these films have
been preserved and will run on a PDP-10 emulator. I haven't seen this
particular cellular atomaton, but then I haven't looked.
Here's the audio commentary that goes with that video, in which somebody mentions that he once called Wolfram on never referencing any of Toffoli's or Margolis' work:
>>Three years after Codd's work, Edwin Roger Banks showed a 4-state CA in his PhD thesis that was also capable of universal computation and construction, but again did not implement a self-reproducing machine.[3] John Devore, in his 1973 masters thesis, tweaked Codd's rules to greatly reduce the size of Codd's design, to the extent that it could be implemented in the computers of that time. However, the data tape for self-replication was too long; Devore's original design was later able to complete replication using Golly. Christopher Langton made another tweak to Codd's cellular automaton in 1984 to create Langton's loops, exhibiting self-replication with far fewer cells than that needed for self-reproduction in previous rules, at the cost of removing the ability for universal computation and construction.[4]
>Actually the constructor arm looks like it got interrupted before it could finish spelling out “MIT"! When it stops at 5:10, it prints out some text at the bottom I can’t quite make out.
>Wasn’t there a section in the CAM-6 book on Banks’s rule, which that looks like?
>Or is this one of those almost-infinite-number of monkey rules, that ALMOST spells out “MIT”, but then suddenly halts? ;)
When I was in elementary school in the 80s, someone in our district retrofit a school bus with two rows of computers running along the sides. The bus would travel to each school in the district once a month or so. We would all walk out to the parking lot, board the bus, and use Logo. It was probably the first exposure to a computer most of the kids in my class had, and I have never forgotten it.
Wow, that was cool. My first exposure to programing was also logo, back in the 80s, back in eastern europe. It was in the form of an afterschool program my father found out about. I loved it. Then when first dabbling in basic my first instinct was to try to draw with it. I think theres something inherently good about computer drawing that attracts kids to computers at early ages, before they are capable of developing interest for abstract ideas and problem solving.
For older kids who want to learn programming I definitely recommend starting with Racket. It comes with cool libraries and small games can be built very creatively. Plus a lot more.
LOGO changed my life! When I learned it as a kid, it made me realize that software was "castles in the sky" and you could do anything you want. 41 years later and a career programmer, I'm now using Lisp in our most modern product. :-) I'll always be grateful to Papert for his work in creating and teaching LOGO.
Which version of Logo and which Lisp? Have you read SICP? Hal Abelson is responsible for getting Logo out of MIT and into the world of the Apple II, and with GJS for SICP. Logo and Lisp connections go way back though, to it's inception with BBN and MIT people.
As a kid, the library had a TI-99/4A with its LOGO and a book by Papert included. I remember it had the most documentation of any piece of software for the machine, which intrigued me. They also had a Coleco ADAM that had LOGO, too, so I used both.
Today, we use SBCL to power a Lisp backend for our product that communicates with an Electron HTML/JS frontend via WebSockets. (See Nebula[0])
Logo was a hard pill to swallow in the 1980's. It had some neat features 'on paper' but it was hard to appreciate them because it was agonizingly slow on the computers of the day.
It was the first programming experience I ever had where I'd type in my function, and then had to wait a while for the computer to do something to it (it never used the word "compiler"), and then it could run. I remember thinking: this makes programming not-fun. I could write it in assembler faster than I'm waiting for the "...." to dance across the screen.
I never really thought of LOGO as a programming language as a kid. It just seemed like a game to me. I also had no concept of anything with a computer being fast or slow so its speed seemed normal.
That's an interesting connection. Logo claimed to be "interactive" but staring at a compilation log go by for 30 or 60 (or more) seconds really pushed the limits of what one might consider "interactive".
Whereas, "Robot Odyssey" was an actual game, and it was a terrific way to get me even more interested in programming. You never had to just sit and wait on it -- or maybe you did but they disguised it so well with animation or loading screens or whatever that I never noticed.
I don't remember the details but I remember some of the kids who were good at math would get to go to the computer room sometimes and instead of math class and we'd make LOGO programs or do other stuff on Commodore PETs. Just seemed like fun. We each had to bring our own disk with our name on it. This was like 2nd and 3rd grade.
I was maybe 8 or 9 at the time. I guarantee I missed 'the point' of a lot of things at that age! Shoot me.
Even today, though, if you told me there was a great new programming language, but I had to wait a minute every time I made a change before running my program, I don't imagine I'd be terribly excited to learn it.
Right next to this on HN is a 2014 article by WalterBright that reports "compiler speed matters a lot". What's the last compiler you used that spent 60 seconds compiling a single file?
Why? 8-bit assembler was simpler and easier to learn than most programming languages. It kinda had to be, given the constraints on CPU's at the time. (And drawing text or graphics was simply a matter of setting values in a memory-mapped frame buffer. Quite trivial, overall.)
With all due respect, bullshit. Preface: I go back to the 70s in programming. I've done 8-bit on 8080/Z80, 68xx/68hc11, 8051, SMT8, 6502 and 2650. I've taught programming. Let's ignore the challenge of finding an assembler running on a common 8-bit home computer and getting it running and how much the early ones sucked. Let's ignore how little doco there was for those early 8-bits (no internet, remember). Let's ignore how user-hostile the debugging and error messages were. Was it easier to explain to a kid "repeat 4 [forward 50 right 50]" or a bunch of memory pokes and all the boilerplate required to get an assembly language program to do anything.
You're special, of course...I get it...superior in your own mind. But based on my own experience, for the vast majority of lesser humans by your measure, Logo is a lot easier than asm as an intro to programming.
Like the poster at the start of the subthread, I was a kid with an 8-bitter and my impression of Logo at the time was similar. It was neat, I read some Logo books but it was too slow. For a lot of things, BASIC was too slow as well and so like many self-respecting nerdkids, I learned assembly and used it a lot. This was typical and there were so many of us, we still regularly cross paths in HN threads like this, mumbling 6502 opcodes at each other.
Heh. My deep pondering was honestly on the Z80 side. CP/M and such. But thinking about "what do I need to keep in the first 256 bytes to make this fly" and all the other interesting quirks of the 6502 are still fascinating.
The assembler is just written in and integrated with FORTH, so you have the full power of the FORTH language to write macros and procedural code generators!
And it makes it really easy to call back and forth ;) between FORTH and machine code, with convenient word definitions for accessing the FORTH interpreter state.
Here's part of my SUPDUP terminal emulator for the Apple ][ with some 6502 code for saving and restoring lines of text in a bank-switched memory expansion card:
Here is a great example of FORTH and 8086 assembly code for hardware control (written by Toffoli and Margolus for controlling their CAM-6 cellular automata machine hardware), starting with "CAM driver routines" and also "creates fast code words for picking out bits of variable X":
>Starting to write programs for the CAM-6 took a little bit of time because the language it uses is Forth. This is an offbeat computer language that uses reverse Polish notation. Once you get used to it, Forth is very clean and nice, but it makes you worry about things you shouldn't really have to worry about. But, hey, if I needed to know Forth to see cellular automata, then by God I'd know Forth. I picked it up fast and spent the next four or five months hacking the CAM-6.
>The big turning point came in October, when I was invited to Hackers 3.0, the 1987 edition of the great annual Hackers' conference held at a camp near Saratoga, CA. I got invited thanks to James Blinn, a graphics wizard who also happens to be a fan of my science fiction books. As a relative novice to computing, I felt a little diffident showing up at Hackers, but everyone there was really nice. It was like, “Come on in! The more the merrier! We're having fun, yeeeeee-haw!”
>I brought my AT along with the CAM-6 in it, and did demos all night long. People were blown away by the images, though not too many of them sounded like they were ready to a) cough up $1500, b) beg Systems Concepts for delivery, and c) learn Forth in order to use a CAM-6 themselves. A bunch of the hackers made me take the board out of my computer and let them look at it. Not knowing too much about hardware, I'd imagined all along that the CAM-6 had some special processors on it. But the hackers informed me that all it really had was a few latches and a lot of fast RAM memory chips.
> Was it easier to explain to a kid "repeat 4 [forward 50 right 50]" or a bunch of memory pokes and all the boilerplate required to get an assembly language program to do anything.
One would think that there's a useful middle ground. My favorite approach would be a FORTHy, postfix-based language where you'd write something like [|50 fd 90 rt] 4 repeat. Something like that would be comparatively easy to implement using a threaded-code approach on a 8-bit machine, which would provide an easy segue into lower-level, assembly programming.
I think Logo is a useful middle ground for novice programmers. But by all means, if you want to do Forth, do Forth. Then you can have all the advantages of the Forth peanut gallery telling any kid that doesn't get Forth they're too stupid to understand computers and all the other toxic baggage that comes from that ecosystem.
Or you can teach a language that caters to programming novices and let them decide if they want to go down towards bare metal or up to more abstract languages or stick to apps like Excel because they really aren't cut out to be programmers.
I concur. The takeaway from LOGO is the idea about what computers can do and how you, the programmer, might approach that. It's a language designed for pedagogy. Programming in LOGO isn't about the language -- or any language, really.
Having done exactly as you say, go down to bare metal programming at IBM and up to full stack web stuff with multiple layers of "high level" languages, its really one's conception of computing that is the biggest determinant in the kinds of software one can write. It's not the tools themselves.
PostScript also has a very nice standard graphics library. It's not turtle graphics like Logo, but it's easy to implement a turtle graphics library in PostScript in a page or so of code.
(Not that PostScript graphics would run very fast on an Apple ][.)
That's right. My "go-to" obnoxious assembly language program I could type in from memory was an infinite loop that screeched the speaker by loading my favorite io address $C030 at an ultrasonic rate.
I had a similar one I'd type in hex at $300, something like:
CALL -151
300:B5 00 20 ED FD E8 AD 30 C0 4C 00 03
300G
(that's a recreation I just worked out, but I think what I used to use was a little different - I forget what technique I used to use to get a semi-random character in the accumulator for it to print)
This filled the screen with scrolling garbage while buzzing the speaker.
Thank you Don! I was going to comment that I wrote a 6502 assembler in Logo for the Apple II and the C64 and it shipped with it and it was documented how to write in assembler. I was hoping to hear some kid learned 6502 assembler from it. That counts you out since you already knew 6502 assembler.
When I was a kid my dad had an Apple II+ and I liked it - definitely don't remember it being slow. MY other two games were Sticky Bear Bop and Defender.
Just that first video alone introduces and explains several key programming concepts: imperative programming with its hidden state and implicit instruction order, procedure calls with parameters, and operator-operand syntax -- all without ever having brought up any of that.
Aaaand once again Gary Kildall gets left out of history. While CEO of Digital Research, the largest software company in the world at the time (besides IBM), he did an entire implementation himself! DR Logo had some innovative graphical features.
Gary Killdall tried to buy Terrapin. It was unfavorable terms and I didn't agree. He went away mad and wrote something in C an implementation of what looked like Logo but I don't know how he choose to implement it. I remember him talking about structs of various sorts at one point, instead of using lists so I assume he was concerned about efficiency. I never had a discussion with them about their interest in pedagogy so I can't comment.
The project evolved into a more advanced 68000 based Smalltalk computer, but I regretted not finishing and releasing the original machine as years later I saw what schools in Brazil were doing with MSX Logo and such. The big mistake in the design was using the same chipset as the TRS-80 Color Computer which had a bunch of needless text and low resolution modes but no nice high resolutions ones.
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:
One of Logo's derivatives, NetLogo [1], seems to be pretty popular among academics as an agent-based modeling tool. It also has a neat browser interpreter. Worth a look, IMO.
Their Twitter thread (to be found on the front page) recently announces a block-based interface, similar to Scratch, Snap...
Example here: https://t.co/aZKscZAHCS
I am honestly wondering which of these alternatives I should start from, to introduce my 8 and 11 yo to programming. Maybe start obvious (so... Scratch, which is used at their school), then introduce the others as needed?
This was an interesting read. I grew up with early personal computers of the eighties and in the geographic area described in the history, so a lot of it is nostalgic. At that time, programming on early home computers generally meant using BASIC (and maybe poke’ing some assembly code) before getting into “real” languages like pascal, Fortran and c in college. I remember thinking logo was a ‘baby’ language and only for kids—-it wasn’t until later on I appreciated some of its features and it’s ties to lisp.
Programming languages like REBOL (or the modern variant Red http://www.red-Lang.org) seem to build on many of the same ideas.
Off topic: This site has a very nice UI. No frills. Almost soothing. Now i have to read that, and the rest of the site has moved to the top of my Tsundoku stack because of that.
Does anybody else feel like that, too?
I really like it. It is so unobtrusive. At first i've been surprised because i disabled in-browser Pdf-reading, but it almost looked like a pdf-reader. All proportioned and positioned just right, no fiddling necessary. And not laggy either. This is how it should be! (For me.)
I wondered about that, since the original document obviously was a pdf. Anyways, doesn't matter because your fork did the right thing for me on 24" @1920x1200, while i've been up for about 7 hours, reading and beginning to feel a little tired.
When i came across your's it eased me into focus. Again: This is how it should be!
edit: i should add i know both the internal ones of Firefox, and Chromium. They usually don't work for me, that is why i disabled them, apart from the usual cargo-culting paranoia to only open documents with native applications ;)
I love Logo. On of the best program was TLC Logo ( The Lisp Company 1983). They had added some extensions that made it even more powerful. The Book, Thininking about TLC logo with the Turtle cartoons (by Allen, Burke, Johnson) was super easy to learn. It's a shame it never made it to the PC stage.
I couldn't stand Logo as a child--my entire childhood goal was to make a video game and Logo was just so slow. Turtle graphics made certain things easy (drawing circles) but there was no way to get some animated sprites on the screen. I pretty much instantly recognized this and stubbornly decided it was toy language for babies.
It wasn't until years later that I realized that Logo had a bunch of neat fundamentals (like functions, which were totally foreign to BASIC-fluent me). It's a shame it wasn't more attractive to a kid like me.
Even in 2020, I was pleasantly surprised that my kids school teaches Logo at the elementary school level!
However, I had a hard time convincing parents who were suggesting it to be replaced with Python or a more modern programming language :(
You lucky! My kid's school teaches Delphi/TurboPascal (8. grade, first programming language course), which they replaced with Lazarus unable to install Delphi on modern PCs.
On one hand, Lazarus and Free Pascal are great so it is nice to see it being used as an introduction to programming.
On the other hand... Lazarus is way too complicated for someone's first foray into programming, IMO. The IDE throws at you a barrage of windows, buttons, lists, etc that can be almost as overwhelming as an airplane's cockpit :-P.
I always maintained that Free Pascal should either ditch the text mode IDE (outside of looking weird to anyone who didn't grew up with Turbo Pascal, almost no terminal/console works reliably enough for it and even in cases where it works, the IDE itself is very buggy - especially in the recent versions) and develop a simple GUI-based one akin to Turbo Pascal for Windows (ie. something that focuses only on small-sized programs) and have Lazarus as the "next step". Hell, it could even be based on Lazarus since most of its functionality is in the form of reusable components.
> I always maintained that Free Pascal should either ditch the text mode IDE
Why not fix the bugs instead? And it shouldn't look weird to anyone who has used TUI programs. In fact, we really should have support for these TUI features (stackable text windows, mouse-controlled menubar and widgets, context-sensitive status-bar) right inside emacs, or some other generic editor. They have stood the test of time wrt. intuitiveness and ergonomics, and it's weird that we still lack them in terminal-like environments.
For the other reasons besides the bugs. I have used the text mode IDE a lot to write smaller programs and it is always a PITA (just not enough of a PITA to open Lazarus, create a brand new project, etc). And some of that is outside FP's control, like Linux terminal emulators being universally broken when it comes to complex shortcut keys that involve function keys and modifiers. Add to that the the Windows console window now also tries to behave more like a Linux terminal (though even before you still had to manually modify the shortcut to not create a 200 line buffer or whatever that causes the IDE to try and use all those lines as its 'screen' - which is especially annoying when it also decides to display a dialog, which is centered at that 'screen' and you have to scroll to see it, usually after pressing a few keys like Alt+F to open the menu and noticing that nothing happens) and you get even more issues.
Honestly the only environments where the FP seems to work (outside other bugs not related to the UI) is DOS and Linux's own console/terminal when running by itself without a window system.
In any case i submitted that message too quickly, that "either" part should have been followed with the alternative to keep it around as a fallback for the platforms where a GUI isn't available or in case someone wants it (though considering how broken it is, i doubt anyone is actually seriously using it).
There's some merit to both sides. As a kid in the eighties, I remember being annoyed by Logo -- it seemed a toy, and even as I child I wanted to learn the tools with which "real programs" (mostly games) could be written.
Berkeley Logo has higher order mapping functions like "cascade" and "crossmap" which I miss in modern Emacs Lisp with its countless packages for example.
If you want something more fancier, NetLogo provides agent based parallelism which is more suitable for games.
The only thing I miss in (Berkeley) Logo is a better fill function.
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 teachingStructure 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. [...]
DonHopkins on July 23, 2018 | parent | favorite | on: Ask HN: Best Lego Mindstorms alternative for fun p...
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).
Here's an excellent mind-blowing example by Ken Kahn of what's possible: teaching kids AI programming by integrating Snap! with existing JavaScript libraries and cloud services like AI, machine learning, speech synthesis and recognition, Arduino programming, etc:
AI extensions of Snap! for the eCraft2Learn project
>The eCraft2Learn project is developing a set of extensions to the Snap! programming language to enable children (and non-expert programmers) to build AI programs. You can use all the AI blocks after importing this file into Snap! or Snap4Arduino. Or you can see examples of using these blocks inside this Snap! project.
Thanks for the kind words both about Logo and about Snap!. That article is in fact not yet officially published, but if I'm reading the ACM legalbol correctly, authors are allowed to put an "author's last draft" version on their institutions' web archives, so that's what you found.
The article has eight authors, and of course the time required to write something is \Theta(n^2) in the number of authors, so it was a long slog, although worth it because in between yelling at each other we had some great conversations about education and computers and Logo technology.
I am inordinately proud of Snap!, which is almost entirely the work of Jens Mönig. My big contribution was to talk him into lambda. (Coming in the next version: APL-style vector and matrix operations. After that we just have to find a way to shoehorn in Prolog and we'll be the unification (pun not intended) of all the good programming languages.)
Hey, how about throwing in a perverted, fetishistic, masochistic programming language like FORTH, too? ;)
Where do you think Logo and Snap fit into the three basic mental structures of psychosis, perversion, and neurosis, as W Watson describes in "The Pervert's Guide to Programming Languages"?
I have hope that Snap! has transcended the self-indulgent Turing Tarpit of Melancholy Languages like Scheme, Lisp (which spawned Scheme during a hysterical event), Smalltalk, and languages that never were, as described on the penultimate page. ;)
Snap! strikes me more as a Hysterical language, frantically pursuing the object of desire, in pursuit of the perfect syntax.
>Hysterical Languages: Hysterical development lends itself to languages that facilitate endless refinements in the code base. The delivered code is never good enough, not merely because of pragmatic reasons but often because of ascetic reasons. The final goal of capturing the elusive domain jargon [59] seems just around the corner, where just one refinement may perfectly represent the domain. Within the hysterical languages there can be two extremes. One extreme is to work towards the capability to easily represent any aesthetic. In this extreme the work and enjoyment are in the development of the language itself [60]. The other extreme is to consciously implement the aesthetic using the language as is [61]. This extreme bends the language to look more aesthetically pleasing. Somewhere in between are refinements to extremely large code bases that must stay available.
>[59] “The overhead cost of all the translation, plus the risk of misunderstanding, is just too high. A project needs a common language that is more robust than the lowest common denominator. With a conscious effort by the team, the domain model can provide the backbone for that common language, while connecting team communication to the software implementation. That language can be ubiquitous in the team’s work.”, Evans, Eric (2003-08-22). Domain-Driven Design: Tackling Complexity in the Heart of Software (Kindle Locations 829-832). Pearson Education. Kindle Edition.
>[60] “Also, I’m a great fan of evolving as opposed to just starting out new. You might fall in love with one particular idea, and then in order to implement it, you go create a brand-new language that’s great at this new thing. Then, by the way, the 90% that every language must have, it kind of sucks at. There’s just so much of that, whereas if you can evolve an existing language — for example, with C# most recently we’ve really evolved it a lot toward functional programming — it’s all gravy at that point, I feel.”, Biancuzzi, Federico; Chromatic (2009-03-21). Masterminds of Programming: Conversations with the Creators of Major Programming Languages (Theory in Practice (O'Reilly)) (Kindle Locations 7017-7021). O'Reilly Media. Kindle Edition.
>[61] “A big part of the modus operandi of the Ruby community is a more fluent approach— trying to make interacting with a library feel like programming in a specialized language. This is a strand of thinking that goes back to one of oldest programming languages, Lisp.”, Fowler, Martin (2010-09-23). Domain-Specific Languages (Addison-Wesley Signature Series (Fowler)) (Kindle Locations 473-475). Pearson Education (USA). Kindle Edition.
Regarding hysterical languages and aesthetics there is the school of thought that small yet very expressive kernels are the most aesthetic. I recall a discussion in the early 1980s with Alan Perlis who claimed APL was a diamond and Lisp was a ball of mud. But it is easier to make things out of mud than diamonds. I also recall a discussion with Seymour Papert (circa 2005) about the next generation Logo. He claimed that one first needs to decide if the design should be driven by engineering or mathematical aesthetics. Sadly, there never was much progress designing the next Logo.
People's taste in programming languages is coloured by their first language(s). But Logo was designed to be a first language, so it shouldn't suffer from people's expectations that it do things like other languages.
According to the wayback machine the last successful snapshot of snap-apps.org was made in June 2018. Everything after is 404, and the domain is inactive, pending delete.
Just a couple highlights from a detailed history of Logo that Brian and Leigh and others posted:
>From Brian Harvey:
>Many, many people have been involved in the development of Logo.
>Wally Feurzeig started the whole thing by organizing a group at Bolt,
Beranek, and Newman, Inc., to study the educational effects of teaching
kids a programming language. The first language they used, like most
programming languages, was focused on numeric computation, and it was
Wally's idea that kids would find it more natural to work in an area
they knew better, namely natural language; therefore, he set up a team
to design a language featuring words and sentences. Wally made up the
name "Logo."
>The team Wally put together at BBN included Seymour Papert and Dan
Bobrow. The three of them are credited as the designers of the first
version of the language; Dan wrote the first implementation. In a BBN
report dated August, 1967, credit for additional work is given to
Richard Grant, Cynthia Solomon, and Frank Frazier.
>Seymour later started a Logo group at MIT, where Logo development
continued. The MIT versions of Logo were substantially different from
the BBN ones, both in the notations used and in the things the language
could do. Most notably, turtle graphics was added at MIT.
>Among the many people who contributed to the development of Logo at MIT,
at the risk of leaving someone out, are Hal Abelson, Paul Goldenberg,
Dan Watt, Gary Drescher, Steve Hain, Leigh Klotz, Andy diSessa,
Brian Silverman... oh, lots of people.
>I think that most of the early documents are out of print now, but whatever
documentation there is of the early efforts will be in the form of technical
reports from BBN and from MIT. You may have to visit Cambridge to find them!
>From Leight Klotz:
>In the mid 1970's, when the AI Lab Lisp Machine project was just
getting underway, Marvin Minsky and Danny Hillis (later to found
Terrapin, and still later, Thinking Machines) put together a project
to build a Logo machine. It had two components: a PDP-11 processor
(the 3500) and a separate vector-graphics display (the 2500). Guy Montpetit, a Canadian
entrepeneur, funded development eventually, and a company called
General Turtle was formed. General Turtle built and sold the 2500/3500
system. Henry Minsky, then about 12, worked on the design of the
2500, using the Stanford Draw program, one of the early electronics
CAD systems. (The 2500 had this really great barrell shifter stolen
from the Lisp machine design, but it was later found not to work, so
it was never used.) [...]
>[...] Like Brian, I've left out many people who worked on Logo over the
years: Brian Fox and Flavio Rose worked for me at Terrapin on a
contract basis briefly, as did vagabond programmer Devon McCullough
(who used to dial in with a 300 baud modem he'd written in entirely
software using the parallel game port, with an 80-column mixed-case
display done with 3x5 pixel characters; when the modem detected the
call waiting click on the line, it would make the Apple II speaker
make the telephone ringing sound -- a feature which I just saw a US
patent filed on, not by Devon.), and the frustrated Sinclar QX programmer,
who I suspect doesn't want his name used. Of course, there were tons
more people at the AI Lab in the pre-commercial days...
>From Lars Brinkhoff
>Hello,
>I'm mostly researching PDP-10 software, especially MIT's Incompatible Timesharing System.
>I have recently stumbled across some of the LOGO group work. I have a
copy of the Dazzle Dart game that ran on their PDP-11/45. It uses the
Tom Knight vector display controller, so it's not easy to run it.
>Maybe it would be possible to get the original MIT PDP-11 LOGO running.
>[...] It's running now.
>[...] Now also BBN PDP-10 Logo, MIT CLOGO, MIT Lisp Logo, and hopefully soon MIT Apple II Logo (direct ancestor of Terrapin Apple II Logo).
Terrapin Logo for the Apple ][ and C64 came with a 6502 assembler written in Logo by Leigh Klotz, that they used to write Logo primitives (for controlling the turtle, etc).
It would be ambitious to make a self hosting 6502 Logo meta assembler, by porting the entire 6502 assembly language Logo source code to the 6502 Logo Assembler!
Leigh, wasn't the assembler that you used for the original Apple ][ version of Logo written in MacLisp running on a PDP-10?
The Apple II Source Code for the LOGO Language Found (adafruit.com)
379 points by mmastrac on Oct 4, 2018 | hide | past | web | favorite | 89 comments
Lars: The link in the article to the code from https://github.com/PDP-10/its is broken. I found a few references to it in the repo. Did you have to take it down, or did you move it somewhere else?
>"I too see the computer presence as a potent influence on the human mind. I am very much aware of the holding power of an interactive computer and of how taking the computer as a model can influence the way we think about ourselves. In fact the work on LOGO to which I have devoted much of the past years consists precisely of developing such forces in positive directions."
>Seymour Papert
>"Logo is the name for a philosophy of education and for a continually evolving family of computer languages that aid its realization."
>Harold Abelson
>"Historically, this idea that Logo is mainly turtle graphics is a mistake. Logo’s name comes from the Greek word for word, because Logo was first designed as a language in which to manipulate language: words and sentences."
>Brian Harvey
>Logo was initially created by Wally Feurzeig, Seymour Papert, Daniel G.Bobrow, Cynthia Solomon and Richard Grant in 1967 as part of a National Science Foundation sponsored research project conducted at Bolt, Beranek & Newman, Inc., in Cambridge, Massachusetts. In 1969 Dr. Seymour Papert started the Logo Group at the MIT Artificial Intelligence Lab. Throughout the 1970s the majority of Logo development was conducted at MIT in the Artificial Intelligence Lab and the Division for Study and Research in Education, using large research computer systems, such as ITS powered PDP-10.
>Our goal is to make that early Logo systems available to a wider audience of enthusiasts for exploration, experimenting and, of course, hacking.
[...]
>MIT APLOGO
>In accordance with Leigh L Klotz Jr., Hal Abelson directed the Logo for the Apple II project at MIT.
>MIT APLOGO was developed by Stephen Hain, Patrick G. Sobalvarro and Leigh L Klotz Jr. It was developed and cross-compilled for the Apple-II-Plus Personal Microcomputer on PDP-10 at the MIT LOGO Group. It is direct predecessor for Terrapin Logo. We have a source code for assembling an improved version from 7/9/81 at its/src/aplogo
Quite the resource list, Don! You should put in links to the Adventure game you wrote for the C64 Logo, and we listed you by name and age.
The assembler was already chosen, probably by Steve Hain or Gary Drescher. I believe it was CROSS. It annoyed me that I would get phase errors if I edited during the first pass which was like 10 or 15 minutes at night so I wrote a one-pass assembler in MacLisp, but it was slower to finish than the first pass of CROSS so I translated it to Logo and Hal said to put it on the utilities disk. I can't remember who added .output and .input but Logo had had them before the Apple II, I think 11Logo had it.
So CROSS made you so cross that you crossed the line by rewriting it in MacLisp, then double crossed it by rewriting it in Logo itself!
Logo Adventure for C64 Terrapin Logo
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.
