HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
71% Positive
Analyzed from 5418 words in the discussion.
Trending Topics
#snap#scratch#blocks#programming#block#https#code#language#why#learn
Discussion (106 Comments)Read Original on HackerNews
That is what eventually led me to build goboscript: https://github.com/aspizu/goboscript
I'm one of the programmers who owe their career to Scratch, this year, I joined https://ente.com as a software engineer. Scratch taught me how to code, and perhaps a bit of real-world engineering indirectly.
I also know that one of the important developers for the Asahi Linux drivers also started on Scratch. I think there’s a lot of real software engineers who started on Scratch (and the Scratch community, which is often overlooked)
WTF. Isn't the whole point of visual programming that you are NOT bound by the limitations of text as a medium? A block refers to a specific variable. It shouldn't matter what it's called, it shouldn't matter if what it's called changes, it should still refer to the same variable even after renames.
Now, custom blocks have a different issue, where deleting one just severs any code that was using it (so if you had some custom blocks in a program: [on start] -> a -> b -> c, deleting the definition for b will mean c no longer gets called). There's now a block to delete custom blocks, so you can make self-destructing code.
Also I made the mistake of writing the manual in MS Word. At the time, I couldn't find a standard way to insert pictures into a TeX document, or I would have used that. (Now, of course, there is a standard way.) There is an effort underway to convert the manual into a web-based format in a git repo that anyone can contribute to, but that effort is 90% done and you know what that means! :)
So it's getting better.
The other thing to remember is that the core Snap! development team is just two guys, Brian Harvey and Jens Mönig. When they're focused on things like trying to figure out how to get macros into Snap!, so that Snap! can truly be a Lisp (right now it's only most of a Lisp), they tend to leave the documentation effort to the community. If they had a larger team I might fault them for that, but with just two guys, I can't really blame them for focusing their efforts on things the community is less able to do, and leaving things the community can do up to the community.
Our team has officially grown to six people, adding Bernat Romagosa, Jadga Hügle, Michael Ball, and Joan i Pelegay. And several Snap! users have made major contributions, especially to libraries that extend the reach of the language. But the interpreter itself is still all Jens.
A big part of it is that you can, to some degree, learn programming from this. But you absolutely cannot learn software engineering from this.
The script is already flipping, with kids making software using AI but they can only fumble forward inch by inch while burning tokens. It would be great to introduce programming in the way it functions in the workplace - we want to make a Mario clone, start with the goal, hammer out the elements to a certain fidelity then let the AI cook.
That said, I think you can learn good fundamentals of SWE with tools like Snap!. You can still learn testing, design patterns, working with APIs, modularity etc.
No it’s not a distributed system, and perhaps the biggest pain point is collaboration is tricky. But still you can learn a ton of cool things without going that far into CS. :)
https://www.youtube.com/watch?v=ITWSL5lTLig
The video above shows keyboard, but the main motivation for the key-based navigation was actually gamepad.
It did have a slight learning curve, but 5th graders were competing just fine against high schoolers haha.
Visual coding is a pain to change and move around quickly. It’s just clutter ultimately - if you know how to actually code.
https://turbowarp.org/1201938491
Though I doubt that happens much anymore.
it's because this is BS and just a toy, it's got no connection to the real world.
from the angle of someone trying to make some toy to teach programming, maybe in their head it's like: oh this is so simple and easy it should work perfectly for teaching
but from my experience, most of my learning came from "whats this?" "how do i make a thing like this?"
this doesn't provide a way to accomplish that or to promote curiosity
I think same applies to basic CS courses teaching bits and bytes, it's not really useful to know what bits and bytes are if you don't understand what they're even used for or why you should know what they are
however, this is just my subjective point of view, maybe it differs for others.
But "no connection to the real world" is hard to sustain once you look at what people actually build with Snap!/Scratch. The ecosystem is full of bridges to physical stuff:
Cameras, microphones, audio, pen plotters, 3D (BeetleBlocks). Snap! 12.1 (video from a few days ago) adds body-language recognition, Bauhaus-style shape compositions, first-class Processes, translation updates:
https://www.youtube.com/watch?v=ID7wYxzHUAc
Arduino / micro:bit / boards (Snap4Arduino, MicroBlocks, many hardware libraries):
https://www.youtube.com/watch?v=Ltzlzk_zkys&list=PL5OeDsbY1E...
Robots (Finch, Hummingbird, Lego NXT, drones):
https://www.youtube.com/watch?v=6_0EqIbTlkk
Sewing machines (TurtleStitch -- embroidery from blocks; one of my favorites):
https://www.youtube.com/watch?v=K6ra5ThxkrE
Web APIs and IoT:
https://www.youtube.com/watch?v=l_P7MoBG250
ML/AI and digital fabrication (Ken Kahn's eCraft2Learn):
https://project.ecraft2learn.eu/
The "what's this? how do I make a thing like this?" curiosity you describe is exactly how a lot of people get pulled in -- making something move, blink, sing, or stitch on a machine they can see, rather than learning abstract syntax first. Blocks are the on-ramp; the project is the motivation.
Different audience than yours, maybe. But "just a toy walled off from reality" undersells what this community has been doing for decades.
Snap! also teaches real computer science at college level while staying accessible to kids -- not a stripped-down kiddie language. Brian Harvey: "Snap! is Scheme disguised as Scratch" (though he notes the original intent was closer to Logo disguised as Scratch):
https://forum.snap.berkeley.edu/t/hygienic-macros/3258/6
Re alanbernstein's point about keyboard vs GUI: Snap! is not keyboard-hostile. It has a keyboard editor for scripts -- build and edit whole scripts without the mouse, block search from the keyboard, infix arithmetic expressions typed left-to-right. Manual chapter:
https://docs.snap.berkeley.edu/user-interface-elements/#sec-...
Demo (typing formulas from the keyboard):
https://www.youtube.com/watch?v=ahHAl3p3gEU
Full IDE accessibility (screen readers etc.) is still a work in progress; Jens and Brian document what's there now:
https://github.com/jmoenig/Snap/issues/1498
so it wasn't the project that was the motivation, it was figuring out how to do it for real, and getting closer to expertise in programming
for example the TurtleStitch, I don't know how to say this exactly, but to me it doesn't strike as something that'd interest people who want to get into programming, but is more like a way to showcase how to do machined embroidery in an accessible way
I might be totally wrong, but my problem seems to be that a lot of this is just about showing off the capabilities of Snap, but it's not really something I would've engaged with for example?
like almost as if the ecosystem simply serves to show off Snap and thus misses the mark?
like Snap doesn't really provide a way to understand how stuff is actually done except for maybe simple logic. So I don't see how it'd be very useful for e.g. learning CS when it's not really something you'd see in the real world, i.e. you're learning a learning platform and some basic concepts
I guess my point is like, if it's not really something that's used in the real world, unlike say JS or Python, why use it instead of getting up to speed in a real language?
again, it could be that I simply don't get it, or that I'm not the target audience, but I feel like there's a reason why these haven't really taken off, and IMO there's no reason why they would need to, because they serve a very specific niche
"This is python, we use it to do professional development work. Here's VS code, we use it to do professional development work. Let's learn them."
6 year olds: "Okay!"
Proceeds to mangle whitespace, variable names, scope, indexing, ==, forgets :, doesn't understand what def is, even after they get all that the program is basically "hello world" print to console.
6 year olds: "Programming is hard and frustrating with little payoff, I don't want to do this anymore"
The one 6 year who who will grow up to be a greybeard sysadmin "This stuff is great! I can't wait to learn more!"
Teachers: "I have no idea what I'm doing, the devs keep saying how Python is supposed to be easy and it's built for learning, but I'm just as confused as the kids."
--
Here's how teaching kids goes with scratch:
"This is scratch, you snape these colored shapes together and they do things like make this character move"
6 year olds: "Okay!"
Proceeds to make games and stories with graphics, sounds and interaction, which they share with their friends, fully editable and runnable in a web environment with zero setup: https://scratch.mit.edu
6 year olds: "Wow programming is fun! I can't wait to learn more!"
The one 6 year who who will grow up to be a greybeard sysadmin "I agree this stuff is great! I can't wait to learn more!"
Teachers: "It wasn't hard to get up and running with scratch, it's very easy to teach and I get it."
Fortunately the name is Snap! so typing it isn't much of a problem. (With the !, which was stripped from the submission title and when most people write about it.)
Edit: Oh, you meant the lambda in the post title? It's not really part of the name, but you can at least type it into Snap itself.
While there, I helped develop this middle school curriculum for Snap: https://bjc.berkeley.edu/bjc-r/course/sparks.html
It was really interesting to attempt a functions-first approach that was still fun - I ended up re-making similar projects for a functions-first Python course as well.
> About Snap!
> Snap! (formerly BYOB) is a visual, drag-and-drop programming language. It is an extended reimplementation of Scratch (a project of the Lifelong Kindergarten Group at the MIT Media Lab) that allows you to Build Your Own Blocks. It also features first class[1] lists, first class procedures, and first class continuations[2]. These added capabilities make it suitable for a serious introduction to computer science for high school or college students.
Jens Mönig was on the Scratch Team (invited by Mitch Resnick). BYOB was presented at Scratch@MIT 2010 explicitly to merge ideas back into Scratch, not to fork the community:
https://scratched.gse.harvard.edu/resources/announcing-byob2...
Berkeley has kept showing up at Scratch conferences (Amsterdam 2015, Bordeaux 2017), and the Scratch forums hosted BYOB/Snap! discussion for years:
https://scratch.mit.edu/discuss/topic/4455/
So "NIH syndrome," "reinventing the wheel," and "fragmenting the community" is pretty much the opposite of how these two actually interact.
Documented cross-pollination:
BYOB => Scratch: custom blocks (Scratch 2.0 took command blocks only, not reporters/lambda). That was an explicit goal:
https://en.scratch-wiki.info/wiki/Snap!
Scratch => Snap!: browser rewrite timing influenced by Scratch 2.0 plans; Morphic via John Maloney; CC-licensed costumes/sounds used under license.
Shared people: Jens (Scratch Team => Snap! lead), John Maloney (Scratch/Morphic; GP session with Jens at Scratch2015AMS), Bernat Romagosa (Snap!, MicroBlocks, Snap4Arduino -- Bordeaux, Snap!Cons).
And so I taught my class using Snap!, because it has:
- Lists that are proper first-class types, and can contain anything, including other lists, and also blocks
- Blocks (functions) that are also proper first-class types, and can take anything as parameters, including lists and blocks.
- Blocks that can create and return other blocks, thereby enabling functional programming
- All the standard list-handling primitives you would expect, like `filter` and `map`
All of which was missing from Scratch when I looked at it six months ago.
Scratch is a toy language, with a deliberate ceiling that you can't get past because of the language's design. Snap! is a real programming language with no ceiling, with the visual appearance of a toy. It takes longer to do anything in Snap! than in a professional language like Lisp or C# or Go or ... well, all of them, because dragging blocks together is a lot slower than typing. But you can do anything you need to in Snap!. There is no artificial limit that blocks you from going farther, the way Scratch has.
P.S. Saying that Scratch is artificially limited is not meant as a dig against the language. It's a deliberate design choice, and it's a fine choice if your intent is to teach people the very basics and then graduate them to another language. It's a choice I disagree with, because I prefer the way Snap! has implemented the same pedagogical choice (you can create tutorials with a limited set of blocks, to avoid presenting complete beginners with an overwhelming array of choices). But it's a defensible choice in many cases (many kids taking a programming class will not have the aptitude — and those who do turn out to have the knack for it can be graduated to Snap! really easily and not have to relearn everything).
Thanks!
Right, you aren't our target audience. We're after the people who aren't going to major in computer science in college, but who're curious what all the fuss is about. They've taken high school algebra, so they know what a variable is and what a function is. (They don't have to know about functions as data, but we hope to teach them that.) These days, they probably used Scratch in elementary school, so we don't have to teach them the syntax of blocks, or what a sprite is, etc.
Nobody's going to come straight out of our class into a software engineering job. They'll have plenty of opportunity to learn that later, supposing that (as happens gratifyingly often) they change their minds about what to study in college because of our course.
They're not (or at least not yet) hackers, in the sense of people whose instinct on meeting a machine is to take it apart.
Oh, P.S., there is one sense in which block languages are better for software engineering: you can have arbitrarily long names of things (including spaces between words), because you only ever need to type the name once, so you can give your procedures self-documenting names such as "convert upper case to lower case letters" instead of ugly "convUcLc".
But you know some wag is going to paste the Pevear and Volokhonsky translation of War and Peace into a block name, just to see if he can. :-) So perhaps there does need to be an artificial limit, at 4096 characters or so, on block names.
They also attend local classes and their teachers switched from Snap to this which is way simpler and stickier with my nephews: https://www.microsoft.com/en-us/makecode
A couple years ago I went through Flexbox Froggy with him out of curiosity, and the really interesting thing was that he was able to complete all the levels but only by dictating to me what to write, because his eye hand coordination wasn't yet up to the task of typing. He has a laptop now and he's getting better but his fingers just don't work very quickly and accurately yet. It's such an interesting thing developmentally that the visual coding approach is helpful for.
But it's different for every kid! He was a very early reader and he's autistic, one of the markers of his presentation of which is being ahead of some developmental benchmarks and behind on others. If you have the resources, those kids coding clubs are all over these days and they do a great job of making it a fun, social activity for a certain type of dorky kid.
I'll have to add it to my list to go and check out any new updates/features they have.
I can NOT wait to get my little one into something like this!
Sure, you could use a Scratch for loop and be done with your cat piano program but have you considered constructing something that theoretically works like a for loop from obscure calculus?
We even have the occult symbol!
Joking aside, if base Scratch does lack a way to express trees as claimed Snap! may in fact be better from the perspective of teaching computer science concepts.
It's clearly designed for older students, but at that point some of the advantages of blocks are lost.
Most of these systems suffer from the 'canvas' model, where you have many stacks of blocks scattered around the canvas as they are created, possibly in no particular or logical order. It's difficult to find things or to get a good overview, and really becomes a navigation problem as projects get bigger. I think they would greatly benefit from a more traditional ide/file type structure, or some other way to structure 'stacks'.
My first attempt to place a statement (play sound at Hz) failed with a Type Error.
Android Chrome.
[...] I'm also a huge fan of Snap!, which has all the advantages of Logo (Lisp without parenthesis) and Scratch / eToys / Squeak / App Inventor family of block based visual programming languages, but all the power of Scheme.
If you know Scheme, then it's easy to think about Snap!: it's just Scheme with a visual block syntax, but with some functions renamed to make them easier to learn, plus all the stage and turtle graphics stuff from Scratch, running in a web browser!
I didn't realize until watching in amazement as Jens Mönig used his own creation, that it also has full keyboard support, so you can create and edit programs without using the mouse!
It's much easier to teach Scheme to kids by teaching them Snap!, because the user interface is so much better than a text editor.
I attended Snap!Con2023 in Barcelona recently, and we discussed some interesting possible extensions to Snap:
Grammar defining blocks. Right now you can create your own custom vocabularies of blocks that fit together in particular constrained ways, by writing JavaScript Snap! extensions. Develop a set of blocks for visually defining new grammars and vocabularies of custom parameterizable blocks.
For example, a grammar for representing plants with seeds, roots, stems, leaves, flowers, petals, etc. You can assemble and edit them manually by dragging and dropping from a palette, or write programs that generated and interpret and transform them, and pass them around as data, for example as instructions to the embroidery machine to sew, or logo turtle to draw.
Turtlestitch - Coded Embroidery:
https://www.turtlestitch.org/page/about
Ken Kahn led a discussion about integrating LLMs like ChatGPT with Snap!. He's the developer of eCraft2Learn for teaching kids AI programming. Ken recently made some cool Snap! extensions for integrating LLMs with the speech synthesis and recognition system, and orchestrating conversations between different characters.
Snap!Con2023: Creative uses of Snap! blocks using large language models like GPT:
https://www.youtube.com/watch?v=d2rNGsbzkXI
Enabling children and beginning programmers to build AI programs:
https://ecraft2learn.github.io/ai/
But when it comes to LLMs, code generation, and code understanding, JavaScript has two huge insurmountable advantages over Snap! or any other block based visual programming languages:
1) First of all it's extremely well known, by both humans and LLMs.
2) And second of all, there's typically no efficient and faithful way to textually represent block based programs in a way that ChatGPT (or humans) can easily understand and generate.
Of course you could just dump out the XML or JSON save file, but that wastes your token budget, and doesn't work well, because the LLM doesn't inherently understand the syntax and semantics of save files the way it deeply groks JavaScript.
You need to define some equivalent text based language to serialize and deserialize your visual programs, or define some equivalency to an existing language, so you can translate back and forth without loss.
Like Relax/NG has an XML syntax and also a simple concise human readable syntax, both which can express the same things.
But no matter what equivalent language you come up with to serialize your block programs into, it'll never be as well known as JavaScript (unless it IS JavaScript).
I think Snap! could take advantage of its equivalency with Scheme, and you could just parse Scheme into Snap! blocks, and the other way around. And ChatGPT knows scheme pretty well, though it's not as ubiquitous and standard as JavaScript.
Logo would not be as good as Scheme, since it has ambiguities, because you need to know the number of parameters a function uses in order to parse it, since it's essentially Lisp without parens. [...]
There's already a right-click menu option called "Lisp code". Take the "turn left 15 degrees" block (the "15" is the default value but of course it's a parameter that can be set to anything), drag it out into the editor, and right-click the block. Choose "Lisp code" and `(left 15)` will be displayed in a results bubble; you can then right-click the results bubble and export it to a file or copy it to the clipboard. If you have two blocks put together then the resulting Lisp code looks like this:
I haven't checked recently to see if they have finished the other half of that feature, the parse-Lisp-into-blocks half. But I know they want it to be in there; I forget what its status was last time I checked.Once you have the text version, you put it back into a split block set to split "by blocks", which gets the list version, which can then be put into the input list of a join block to get the code again.
This is technically discoverable from within Snap itself since they provide a library wrapping these steps, but it's not the first place you might look if you don't know it already exists.
Whether using text with LLMs in Snap! is actually a good idea is up for debate, but it is doable.
Most of them will never become professional actors, authors, mathematicians, artists, photographers, etc ... and yet they will rely on those skills, on their own or combined, pretty much every single day of their lives.
LLMs, at least the current crop, are skill multipliers. If your skill is positive and large, you'll get great results. If your skill is positive and small, you'll get small results. If your skill is negative, the LLM will harm you more than it helps you.
At the moment, I would never encourage any of my students to go into software engineering. It seems to me that's rapidly becoming a field where a small competitive handful will be making millions and everyone else will be unemployed.
That said, I have no problem teaching some programming. We're going to be making autonomous greenhouses soon, with windows that open or whatever, and they'll be using Scratch to program their micro:bits.
Anything that empowers you to do stuff is a good thing.
Because it makes your brain think through problems, breaking them down to the point you can build a solution from the smallest pieces. AI may be a big part of the future, but we need to maintain our own human creativity and problem solving skills, and learning the tools that are available will help us to build and create useful things throughout our lives.
Why do we teach them to read, we have text to voice?
Why do we teach them to broom, we have Roombas?
Why do we teach them to do the dishes, we have dish-washers?
</sarcasm>