LOGO >> Scratch
Schools should teach LOGO to grade schoolers. Two birds with one stone. Learn something about computers and learn how to use a keyboard.
Schools should teach LOGO to grade schoolers. Two birds with one stone. Learn something about computers and learn how to use a keyboard.
I remember I was particularly proud of drawing a simple house with an animated dashed border. Since we did not have hard disks yet and floppy disks were very limited in number, our computer teacher helped with quickly transcribing the code from screen onto a paper, so that we don't lose the program I had just written and demonstrated to others.
I have written a blog post about my happy little experience with Logo programming, in case anyone wants to read more about it: https://susam.net/blog/fd-100.html
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.
As someone who learned to program in Scratch many years ago, don't worry about it. I've written in languages from Python to Assembly, I've worked professionally as a programmer, etc. It's fine.
As far as I can tell, the best way to teach someone to program is to enable them to pursue their own projects and to help them when they get stuck before they get so frustrated they give up. (Maybe there are learning styles I'm not aware of, this is true of myself and of people I've met.) When I meet people who want to program but can't (which has happened approximately twice, one of them did come back to programming after a few years & succeeded), it seems to be because they didn't have access to sufficient support, and stupid issues (especially development environment issues) wore them down.
Scratch is a tremendous help in both respects. It comes out of the box which cool stuff to do (eg, I made dumb games and animated little movies). It's simple enough for nonprogrammer adults (like teachers) to learn and help debug.
7. On the other hand, we are about to unveil a radical unhiding: showing users the innards of expressions and procedure bodies via macros and metaprogramming. The central feature making this possible is the ability to convert back and forth between executable code (the blocks and scripts that we've always had) and syntax trees: lists of lists of the individual blocks and constant values (such as text and numbers), the building blocks of expressions and scripts. That conversion overcomes the only weakness of block languages, namely, that programs aren't data, which makes them harder to manipulate programmatically.
7½. Pedagogically, this is an extension of the self-reflection by means of non-hidden continuations, which call attention to the sequence of events in executing a script, and which we inherited from Scheme. Continuations are conceptually simple for the implementor, since they already exist in any interpreter for any language, and it's just a matter of making them visible to users. But they're not conceptually simple for users! The fact that they can be called repeatedly, and from outside of the script in which they were created, feels like magic. And it is; it's the magic of "everything first class." But the point here is that we didn't add this feature in response to a specific pedagogic need. Rather, explicit continuations help advanced programmers write advanced programs, and a few library blocks. And they're a way to plant the flag of Scheme in Snap!, which was a big part of our motivation.
I think it depends on what you're trying to teach kids. For young kids, scratch is probably a fine introduction to basic procedural coding (which is kind of funny since it's implemented in a descendant of the prototypical OO environment.) You can teach the same concepts with LOGO, and they did in the 70s. But it's a LOT easier to teach things like language processing and language concepts like recursion and evaluation with LOGO. But there's some question about whether or not kids younger than 8 or 9 can internalize these concepts. In the states we even hold off until around age 12 or 13 before introducing such things.
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.
Snap! == Scheme ** Scratch
Snap! is a blocks based visual programming language like (and inspired by) Scratch, but with the full power of Scheme, an undiluted superset of Logo's and Scratch's capabilities, including user defined blocks, closures, and even continuations!
More about Snap!:
https://news.ycombinator.com/item?id=20309162
>One of the coolest ways to learn programming I've ever seen is the Snap! visual programming language, which is written in JavaScript and runs in the browser. https://snap.berkeley.edu
>It's the culmination of years of work by Brian Harvey and Jens Mönig and other Smalltalk and education experts. It benefits from their experience and expert understanding about constructionist education, Smalltalk, Scratch, E-Toys, Lisp, Logo, Star Logo, and many other excellent systems.
>Snap! takes the best ideas, then freshly and coherently synthesizes them into a visual programming language that kids can use, but is also satisfying to professional programmers, with all the power of Scheme (lexical closures, special forms, macros, continuations, user defined functions and control structures), but deeply integrating and leveraging the web browser and the internet (JavaScript primitives, everything is a first class object, dynamically loaded extensions, etc).
https://news.ycombinator.com/item?id=23053999
>Snap! has the full power of Scheme (first class functions, user defined blocks, recursion, closures, continuations, JavaScript integration, etc), with a visual block syntax and playful graphical environment with turtle graphics like Scratch.
>The following post is a couple years old, but maybe somebody can provide some updates and recent info!
>Edit: I should have RTFA first, which is totally up to date, just published in 2020, from the turtle's mouth:
https://escholarship.org/uc/item/1623m1p3
>Brian Harvey’s Personal Narrative on Snap!: Scheme Disguised as Scratch
>In 2009, the University of California, Berkeley, was one of several universities developing a new kind of introductory computer science course, meant for non-CS majors, to include aspects of the social implications of computing along with the programming content. Scratch wasn’t quite expressive enough to support such a course (it lacked the ability to write recursive functions), soProf. Daniel Garcia and I thought “What’s the smallest change we could make to Scratch to make it usable in our course?” After 20 years teaching Structure and Interpretation of Computer Programs [Abelson et al.1984], the best computer science text ever written, I knew that the answer to “what’s the smallest change” is generally “add lambda.” I joined forces with German programmer Jens Mönig, who had developed BYOB (Build Your Own Blocks), an extension to Scratch with custom (user-defined) blocks, including reporters and predicates. [...]
Anybody else in Barcelona for Snap!Con this week? Let's meet up and say hi!
Just kidding. But taking a random collection of APL concepts and applying them to a graphical editor probably isn't the recipe for success you may be thinking it is.
But in the tradition of the Computer Science Logo Style series (which built up to things like toy pascal compilers and expert systems), I occasionally dream of learning enough Snap! to port Iverson's samples from this lecture...
I agree with Iverson that notation is important. Just look at Maxwell's Equations. There were 26 of them until Heavyside noticed they could be put into vector form and suddenly there were 4 (5 if you squint.)
But yes, just because an approach is popular doesn't mean it's useful in all cases. Just look at Python.
I was lucky enough to be able to talk with Doug Engelbart in the 2000's. One of the points he brought up, which was elaborated in Bardini's book about him, was the source of friction between him and Larry Tessler. Engelbart liked to emphasize functionality of notation (be it textual or graphical) over ease of learning. "If it was important, the users would take the time to learn it," is a paraphrase of what I think he was saying. Even when he was at SRI (before working on the Alto) Tessler was advocating for "easier to learn" abstractions.
Where is the truth? Somewhere in the middle? Hard to say.
(where does Ableton Live fit into the metaphor above?)