December 26, 2007
Leon recently posted a link to a great blog entry on rediscovering Logo. You know, Logo -- the one with the turtle.
I remember being exposed to Logo way back in high school. All I recall about Logo is the turtle graphics, and the primitive digital Etch-a-Sketch drawings you could create with it. What I didn't realize is that Logo is "an easier to read adaptation of the Lisp language.. [with] significant facilities for handling lists, files, I/O, and recursion", at least if the Wikipedia entry on Logo is to be believed.
Although I was eternally fascinated with programming, Logo held no interest for me. It seemed like a toy language, only useful for silly little graphical tricks and stunts with the turtle. But apparently there was a real language lurking underneath all that turtle graphics stuff. Brian Harvey is a Berkeley professor who not only co-wrote Berkeley Lisp, but authored three books that, amazingly, teach the whole of computer science using nothing but Logo.
If you have no time to skim the material, and you're still convinced Logo is a graphics language for little kids, check out a sample Logo program that Brian put together to impress us. I'm impressed, anyway.
Logo is much more than the thin wrapper over turtle graphics I thought it was in 1986. But turtle graphics still-- how shall I put this? -- suck. I took two new books with me over the holiday vacation, and both deal with something akin to the spiritual successor to Logo-- the Processing environment.
Both Processing: A Programming Handbook for Visual Designers and Artists and Visualizing Data paint a picture of the Processing environment that strongly reminds me of Logo. But Processing doesn't offer up a new Lisp syntax -- it sticks with good old-fashioned Java.
If we didn't care about speed, it might make sense to use Python, Ruby, or many other scripting languages. That is especially true on the education side. If we didn't care about making a transition to more advanced languages, we'd probably avoid a C++ or Java-style syntax. But Java is a nice starting point for a sketching language because it's far more forgiving than C/C++ and also allows users to export sketches for distribution via the Web.
The focus of the Processing environment is squarely on learning while doing, which is definitely one of the tenets of Logo.
If you're already familiar with programming, it's important to understand how Processing differs from other development environments and languages. The Processing project encourages a style of work that builds code quickly, understanding that either the code will be used as a quick sketch or that ideas are being tested before developing a final project. This could be misconstrued as software engineering heresy. Perhaps we're not far from "hacking", but this is more appropriate for the roles in which Processing is used. Why force students or casual programmers to learn about graphics contexts, threading, and event handling methods before they can show something on the screen that interacts with the mouse? The same goes for advanced developers: why should they always need to start with the same two pages of code whenever they begin a project?
In another scenario, if you're doing scientific visualization, the ability to try things out quickly is a far higher priority than sophisticated code structure. Usually you don't know what the outcome will be, so you might build something one week to try an initial hypothesis and build something new the next week based on what was learned in the first week.
It's an admirable philosophy, and it's especially appropriate for a domain-specific language. If you're interested in graphics and visualization -- if you're truly looking for a modern Logo-- leave the turtles behind and check out Processing instead.
Posted by Jeff Atwood
I also like NodeBox for generating procedural graphics in Python (Mac only). Some of the example graphics produced are very impressive, and the generating code is surprisingly short.
There's also a project for a cross-platform Ruby equivalent underway (Scribble?).
I don't understand this fascination with Lisp. Why put all of your emphasis on "elegance" and lines of code. I prefer a easy to follow form that is verbose. Why be vague and cryptic?
(I know this post is about Logo, but upon reviewing the sample program, I can see the relation to Lisp; the same argument applies)
I never used logo. But I figure it was a favourite of many... cool
"that is verbose. Why be vague and cryptic?"
These are not opposites. Verbose code makes the initiation easy and the work hard.
Anyway I didn't know lisp when I was exposed to logo, but I remember the lists, and the fact that the file I/O and file system seemed somewhat strange and nonintuitive, at least compared to the language proper.
(Ah, and ruby may have gotten its symbol notation from there.)
I can't agree more with the last line from Processing you quote. I just wrote my thesis in Java. I didn't have to hand in the program, only the results, and before starting to program, I couldn't oversee which parts I would and wouldn't explore.
Therefore, for every method I had to decide "will I spend a lot of time to make an elegant data structure and adapt easy later, or will I 'hack' this together because I will probably never adapt or use this code"?
In the end, I have made a mishmash program with quite a lot of really elegant methods, and some complete hackerish that was very specific to one test set. Actually, the core of my program is something "i am not proud of", but in the sense of code hiding it was a nice black box having a comment "do only use this on the turtle layout" (where turtle is a mahjong term, not something to do with logo).
A friend of mine who did saw the code was repelled by it, however I think it has saved me a lot of time to NOT do every bit in extreme neat code style.
No...not logo...i'm begging you... I'd rather do a whole day of TURBO PASCAL 7.0 than one minute with Logo...
*runs away screaming*
(yes. I was forced to learn Logo in school. Yes I loathe it to this day, even more than Pascal)
Processing is nice, and some 2 years ago when Actionscript 2.0 ruled the Flash landscape I'd have agreed that processing would be your best bet for "learn as you go" visual programming.
I agree there is something uniquely rewarding to programming visual results and not just command-line apps, and I think it's very compelling to a new/hobbyist programmer and as such can be a great teaching vessel.
While Actionscript itself may not be as fully matured a language as Java, I would staunchly argue the Actionscript3.0 API is a tightly integrated singular platform that offers far more potential and ease-of-use than the hodge-podge collection of importable libraries to be used with processing.
Furthermore, with MXMLC, Actionscript3.0 can be coded and compiled entirely with your own free text-editor...there is no need to actually own Flash, to create a .fla file, or to pay Adobe any money.
Flash apps are also easily shareable online, and play nicely with the browser as well as desktops via A.I.R, as well as providing their own ability to open Socket connections for fun synchronous multi-user applications. (like Games! a new/hobby programmer always wants to make games. ;o))
In summary: I think Actionscript wins for its environment and interoperability, even if it's ECMAScript-based language is lacking "mature" features (like Enums) that can be found in Java 1.5+
Lots of Irritating Silly Parenthesis...
What I think is truly interesting here is the resurgence of Functional programming languages. One of the more interesting projects I've looked at is the Microsoft Research Language F#, which is a .NET language based on OCaml.
With the craze in object oriented languages, we sometimes forget that certain types of problems are more easily solved with different paradigms.
Logo is certainly based on Lisp. Logo's FIRST and BUTFIRST operators are Lisp's CAR and CDR. The syntax is, of course, very different, but that reflects the designer's intention that the language be as easy to use as possible by the intended users, children. In discussing Logo, it is essential to not forget that the language was designed for pedagogy - to make it possible for children (not high school students) to enter a world where they could construct programs and reflect on the process of programming.
The same applies to turtle graphics. The purpose of turtle graphics was not to enable creation of photo-realistic rendering, or to do scientific visualization. The aim was pedagogy, to provide a compelling domain where one can think about programming. Turtle graphics provide some very important pedagogical features. First, because turtle motion is *relative* motion (forward/back, turn left/right) it allows a child to think of the drawing (or program) by using her own body, to "play turtle". For children, the ability to think of a program concretely is essential, and nothing is more concrete to a child than her own body. Second, turtle graphics abstracts away coordinate systems, so a child can make drawings without having to first master matrix multiplication.
As a third, but lesser point: when properly done, turtle graphics encourages modularity and re-use. Why? Because turtle graphics (sub) programs can be composed, but only if the program has no side-effects (other than the drawing itself). That is, if the program, on exit, leaves the turtle's heading and pen-state unchange, you can build larger drawings by combining smaller drawings. This idea, in miniature, is one of the core ideas we need to build re-usable, composable programs.
In sum: criticize the language according to its intended purpose (and the historical state of computing at the time.) Logo remains an excellent language for teaching. Logo is very easy for beginners to start with, yet allows one to grow into (most, if not all) the subjects of academic computer science.
Disclaimer: I worked on Logo at the Logo Laboratory at MIT in the mid 1970s, and was one of the developers who built Logo for the Apple II. I knew Papert and Solomon.
I only used logo to draw circles and stuff in elementary school... later on we used Logo Writer (basically the same, but the turtle had a turtle shape :D:D:D ). When they started to teach us programming we used qbasic... ah, the memories
They didn't teach us programming in elementary school (or high school, for that matter). However, I think it's funny for people to use execution speed as an excuse for writing something in Java, since that was the primary excuse against writing anything in Java for many years (and still is in some areas). In general, I still find the execution speed of almost anything written in Java appalling on a Windows desktop, and with the bickering between Sun and Microsoft over the proper way to write a JVM, I doubt it's ever going to get significantly better.
Of course, once you get the JVM and the program loaded into memory and running, the program itself is usually responsive enough for many uses, but then so are most scripting languages.
Real programmers code in Logo !!!
(no pun here)
The same comments where made about Lisp and (Object) Pascal...
P.D. Karel it's a good alternative, a mixture of Logo and Pascal...
I always preferred the use of Lost In Stupid Parenthesis.
As for why you should use it, after spending a bunch of months the only reason I could think of it was the only language that AutoCAD supported for building additional capabilities.
People who like Logo should check out Turtle Art on the OLPC (http://wiki.laptop.org/go/Turtle_Art). It's like Logo but you build your program graphically, using pieces that fit together to show the flow of control. The thing I love about it is that the program and turtle art workspace are the same thing -- it's like building something on a lab bench instead of writing a computer program. It's also one of the most polished XO activities, probably because it was written for a commercial robot product and then ported to the XO.
LOGO is so great I learned it when I was seven years old in the public library in Mexico.
I could say that I know 5 other sw developers that participated in the same program. Coincidence? I don't think so.
LOGO is a joy to program and a joy to learn. And I don't what language provides the WOW factor that drawing a star with a loop had back then...
A few details for people interested in Logo:
I describe the Lispy aspect of the language a little while ago here: http://blog.ianbicking.org/2007/10/19/logo/ -- someone mentioned Ruby, and it wasn't directly inspired by Logo, but Smalltalk was inspired by Lisp, and also Logo very specifically, and Smalltalk was a strong influence on Ruby.
Outside of Logo, for 3D worlds there's Alice (http://www.alice.org/) and VPython (http://www.vpython.org/). I've heard good things about Panda3D (http://panda3d.etc.cmu.edu/), but it's probably not as beginner-oriented as Alice and VPython. Pyglet (http://www.pyglet.org/) is shaping up to be pretty cool too. On the Ruby side there's also the clever environment of Hackety (http://hackety.org/).
There's lots of other things out there too, of course. I wouldn't start with UCBLogo (too retro), and certainly not Java (where's the interactive fun and experimentation?)
I was forced to learn logo in school as part of our syllabus. i always thought it was for a joke like most of what we were taught. good to know it was of any use at all.
It may be primitive... but it remains the only language I've been able to teach a four-year-old to program in. (Said four-year-old - who attended an elementary school I worked in during my mis-spent youth, was exceptionally advanced at maths - he probably has a PhD now! Nevertheless, he didn't "get" BASIC at the time, so I tried Logo, and he was sending the turtle off by itself in minutes!)
That LOGO is a form of Lisp seems to be one of those well-kept secrets.
It's something I stumbled across when doing some of the code examples from _Godel, Escher, Bach_ with the LOGO interpreter that came with the Amstrad-PC (c.1985), and then later discovering that they were actually Lisp.
Back then it was being touted as the language for learning with; and since, it has managed to rise without trace.
Your cost benefit analysis breaks down quickly after you consider the fact that most programs are run N number of times, not once. Also most programs are used by PEOPLE, who are in turn being paid. The slower the program, the more time it takes those PEOPLE to do their work, and hence, the more money it costs.
Just today I was trying to decide if I would spend time learning Processing or NodeBox. By the way, _why is working on something similar called Shoes.
I think that visualizing data with processing is becoming a mainstream industry. That's why I invest so much into NDepend (http://www.NDepend.com), which basically lets users visualizing data about the structure of a code base, which is complex data.
I don't know about Logo but yet, with GDI you can do a lot. Not to mention the incredible possibilities of WPF.
For young kids (elementary age) I wouldn't recommend Processing.
For young kids I'd recommend Scratch from MIT.
Bungeelabs and others are also starting to develop web-based IDEs, although not with beginners in mind.
Sometimes it's just the right tool for the job.
I have a few algorithm-derived drawings to create for a project. I had considered a programmable CAD package, such as the freeware AllyCad http://www.allycad.com/. It's nice, but a lot to learn.
I considered shelling out cash for Visio and doing VBA.
I looked at SVG a while back, but it seemed to be a pain in the neck. Then I saw this blog entry. Wow, I could have used Logo.
Unfortunately, last summer, cleaning out the garage, I threw out my unused 20+ year old 5.25 floppy with IBM Logo built on the UCSD P-system. What would I run it on anyway? The overclocked (8 MHz) PCAT I didn't throw out?
Friday I downloaded MSWLogo. http://www.softronix.com/logo.html Today, 13 functions later, my drawings are done, saved as .gif's and printed on my laser printer.
I may not like the syntax and punctuation, but it sure did the job.
I've always thought the Rebol language is a natural successor to Logo. http://www.rebol.com
Rebol is a friendly cross-breed of Scheme, Logo and Forth. It is cross-platform, very tiny, and has built-in networking protocols. The sample logo program you linked to would look like:
choices: func [menu sofar] [
if empty? menu [print reform [sofar] exit]
foreach item first menu [
choices next menu reduce [sofar item]
[small medium large]
[vanilla "ultra chocolate" lychee "rum raisin" ginger]
Sorry to sound like an infomercial. I thought some might be interested.
I wish I could remember more details, but this topic brings back memories. Back in high school, there was some weird kid named Steve working furiously in a corner for months to get his grand AI program to work. He wrote the whole thing in Logo, which we all thought was madness, but it makes some sense in light of this comparison between Logo and Lisp. I had no idea that might actually have been a reasonable choice. We just thought it was more a matter of him being too afraid to write in a real language. (Our definition of a "real language" was probably Apple Pascal, I'm thinking.)
I remember him spending a long time on that project, and hitting a brick wall imposed by the limitations of the primitive Apple computers we had. I think the teacher wound up giving him the grade anyway, because the source looked plausible, even though it wouldn't all fit into memory or whatever.
I used to think he was a hopeless dork, but now I wonder. I bet he managed to go a lot further in life than I have with that kind of vision.
I owe Steve some overdue respect.
OMG, never thought it is still alive! LOL, I used to play with this language when I was 10.
* Running away to download the Processing :) *
There's some pretty impressive stuff being done with Processing, especially with its support for OpenGL. There's some beautiful graphical work being done by Robert Hodgin over here: http://flight404.com/blog/
There is a version of Logo for Palm OS and with a bit of messing around (and some extra software) you can even get it to run on modern Pocket PCs. There is a post about it here:
I'd love to hear/read your follow-up comments when you've read 'Processing' and 'Visualizing Data'... or will you be posting them as Amazon reviews?
And I'm sure we'd all love to see any visualizations you do.
On the note of data visualisation, you might be interested in this 'alternative' (in a way) to Processing that does some seriously cool stuff and sports a visual/modular coding interface:
Unfortunately requires DirectX. vvvv is the only reason I have a windows box.
I never got to play with LOGO.
Maybe I can play with the classes in System.Xml to make SVG files.
"If we didn't care about speed, it might make sense to use Python, Ruby, or many other scripting languages."
I love this fallacy. It's the classic language speed is more important than programming speed fallacy. That used to be true, it isn't any more.
Let's say we have to write a program to analyse a data set and report it to our boss. Jeff starts the program in C++ and I start writing it in Python.
It takes me two days, it takes Jeff three. Let's say my program takes ten times a long to run than Jeff's. Jeff's takes two hours, mine takes twenty. Even so, I've still beaten Jeff.
I'm still a day cheaper than Jeff too. Twenty hours of CPU time is much less than one day of work time. We charge a day of development at roughly a thousand for a day. I can get a cheap PC for around 300 plus 0.10 of electricity. I've still got 700 more than Jeff.
It's even worse, let's say that the reason my program is slower than Jeff's is because of two or three slow routines. I can factor those routines out and write them in C++. This task might take a couple of hours. My program is now just as fast and I've still beaten Jeff.
You'd have to be nuts to use C or C++ on new project.
I remember using Logo in the 5th Grade and actually entering a programming competition with a Logo Program. For how simple the idea is you could actually do a lot of fun things with it especially for kids. Making your own simple games as well as some that are a lot more advanced in the commands and the visuals. It might sound bad, but the way that I learned how to structure code into subroutines can still be seen a little in the way that I currently write code and making sure that I try to seperate input, processing and output.
Don't forget the LEGO TC Logo. Build a car out of Legos and move it around by using a Logo program.