Snap! >> Logo >> Scratch
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!
Snap! even sneaks in a bunch of APL-inspired blocks...
Kill it before it gets to the children!
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?)
In this metaphor, Ableton Live would be bought by Gibson and immediately end of lifed.