I taught a high-school Intro to CS course last year with the TEALs program (https://tealsk12.org). I was very unenthusiastic when I heard that the first semester was taught using Snap, but I was wrong. Snap is a pretty awesome way to introduce someone to programming (much more powerful and reliable than other block-based programming environments I've tinkered with like the Kano kit).
The one really terrible thing about the current iteration of Snap (that I think would be trivial to solve?) is that you have to remember to save your work. I don't think that's a normal thing for people to think about on the web in this day and age, and I have seen many students (and my own children) lose large amounts of work due to this. It's extremely discouraging.
Other than that though, the snap language/environment is quite nice.
Trust me, I know. But even here we run into issues, such as projects over the local storage limit, and the fact that (well, until COVID...sigh), a non-trivial number of students were in computer labs that contained programs like deep freeze making anything local storage based headache inducing as a means of support.
Depends on what you're doing, but coding is probably the obstacle. There's about 4 of us working various amounts of part time.
In the case of auto-save, there's a lot of unsettled design trade-offs, and other needs keep coming up. But if you're curious, you're welcome to check out the GitHub: snap-cloud/snapCloud is the backend, and jmoenig/snap is the main IDE.
I thought the message broadcasting and asynchronous behavior of Snap is really cool, specifically how sprites can have multiple code blocks each responding to messages or events.
I'm actually listening to a TEALS meeting right now! Funny to see it on HN.
I can second that, I have seen people frustrated after loosing work in Snap! by missing to save. But then that's maybe also a lesson people ought to learn early-on when creating stuff on the computer: safe early and create backups :)
Jens Mönig and Brian Harvey both received a National Technology Leadership Summit (NTLS) Educational Technology Leadership Award for their impact on educational technology over the course of a lifetime, for their work on Snap!
>[...] Snap! is a remarkable technological achievement. However, like Logo, its greatest achievement is arguably the educational philosophy that it draws upon and supports, and the associated community drawn together by this philosophy. In a very real sense, the Snap! community embodies the spirit of the early Logo community, extending it for the modern world. The NTLS Educational Technology Leadership Award, awarded to Brian Harvey and Jens Möenig, is presented in recognition of that accomplishment.
It’s awesome to see Brian Harvey get recognition. He’s an incredible educator - the finest I’ve encountered - and I’ll be forever grateful that I got to experience that at Berkeley before he retired.
I have mixed feelings. Learning Lisp was extremely eye-opening, and I was amazed at how much could be done with such a simple language. It inspired me to learn way more about theoretical CS, knowledge which continues to serve me to this day, even though I wound up in a different field. I definitely came away a believer in Greenspun's tenth rule.
OTOH, for most 61a students, this course (indeed the entire major) amounts to a very expensive form of vocational training. Developing an aesthetic appreciation for finely crafted code seems somewhat orthogonal to their end goal, which in 99% of cases is getting a high-paying job writing Python, C++, or some other A-list language. I can't really see the benefit of a formative semester spent on honing their Lisp chops. As educators, we want to believe that the latter leads to the former, but I'm a bit skeptical.
Here's Jens Mönig's opening keynote address to Snap!Con20, in which he discusses HyperBlocks, which add APL-like vector and matrix processing to Snap!
His delight in programming is so contagious even with social distancing and teleconferencing!
Snap!Con20 Keynote - Hyperblocks
Opening keynote address of the Snap! Conference 2020, UC Berkeley, about APL-style hyper-operators (working on scalars, vectors, matrices and multi-dimensional data) and the fun to be had applying them to media of all kinds
That is some seriously impressive improvement on performance and memory use; I'd be interested to know what exactly they did to do that (ex. did they realize they could rearrange something to do the same thing with less work, or is this just a lot of little optimizations adding up?).
Also cool, if a little weird to me, to see full-blown map-reduce and APL-like features; I feel like that moves away from the "beginner's language" that I think of when I think of Snap, and builds at least the ability to take it a lot further. Which, honestly, is just really cool:)
The memory-footprint and performance improvements basically boil down to a departure from pre-rendering and caching all the graphics to redrawing them just in time. We were delighted to find out that rerendering complex graphical shapes in modern browsers can be done faster and with less memory penalty than pre-rendering and caching.
Here's part of a presentation I drew up earlier this year with a few slides outlining the architectural changes:
The idea is to be able to easily move someone from beginning features to more complex stuff. The APL functions are new, but in the past this meant story-based projects to using tools like lambdas, map, filter, etc. When done as part of a course, it's definitely something students can learn.But you can do everything in Snap! without those features, too. (The FOR EACH construct for example works just by dropping in a stack of blocks, but you could choose if desired to pass in a lambda and do different parameter binding...but not many people really do that. ;))
We've played around with various ideas for how many blocks to show and it's definitely a work in progress constantly, but the current design is because most people are using Snap! in the context of a course where there's a push to learn those tools and so they get used pretty frequently. :)
I'd suggest TIC-80 [1] as an intermediate step from Snap! to larger IDEs. TIC-80 documentation [2] is a little thin, but overall it's a very pragmatic integrated development environment that combines sound, sprite, map and code-editor into one very simple IDE environment (no debugger, though, only rudimentary logging).
You have a choice between multiple script languages (Lua, Javascript and more). The run-time library [3] only has a handful of simple functions but is feature-complete nonetheless (plus there is some address-based peek/poke API to do more advanced, low-level stuff).
I'd imagine learning javascript programming by starting game-development in TIC-80 to be much more straight-forward than attempting to wrestle with the complexities of HTML5+CSS+javascript+tooling for in-browser programming.
Most students end up taking a course in another language. At UC Berkeley, they go from Snap! to Python, and it's typically something like VSCode or Sublime as the IDE.
On my when-things-slow-down list is to write a version of Structure and Interpretation of Computer Programs using Snap! as the language, aimed at high school kids, so replacing the examples that require calculus, for example. I (no doubt naively and arrogantly) can't help feeling that a transition from Snap! to any language that isn't Scheme would be a step downward.
I would rather know what they did to warrant using over 20x the memory they are using now. I'm surprised people aren't embarrassed about that type of thing, but what happens here is people brag about fixing an egregious mistake.
If someone makes improvements on a mature program that a lot of people have worked on, that is impressive. If someone uses 20x the memory they need, that is fixing something that should never have shipped in the first place.
Then they say this memory reduction is reducing the program's ecological footprint. DDR4 uses 1.5 watts. In one day your refrigerator will use more electricity than your memory will in a year.
Can anyone tell be in one or two sentences how this relates to Scratch? Is is an alternative, is it used by Scratch, is it something different although it looks very similar?
It's based off Scratch's UI but doesn't share any code. It has a lot more features that delve more into computer science instead of scripting like in Scratch. I believe it was also available in-browser before Scratch was, but I'm not sure.
Snap! is designed to allow students write code in the same way they might in Scratch, but then move them on to exploring CS concepts. It's also somewhat more extensible, including allowing people to make blocks pseudo-natively in JS. (We don't really expect students to do this, but it's a great way for instructors to build tools for assignments or just experiment with ideas not yet in the language.)
The first version, BYOB, was an extension of the Scratch 1.4 source code, but since then we have moved in different directions. But we are still inspired by how careful they were in designing visual metaphors for computer science ideas and have tried to extend that care to things like lambda and object inheritance.
Here is another keynote address about Snap! that Jens Mönig was invited to give recently:
Keynote by Jens Mönig "The Music Comes Out Of The Piano. Learning With Computers & From Computers" during ECTELFI20 - the joint online conference of the 15th European Conference on Technology-Enhanced Learning (EC-TEL20) and the 18th Annual Conference of the Educational Technologies SIG of the German Informatics Society.
Note: it’s about the visual programming language (2009) and not about the band (1989) or the package manager (2014.)
:)
(full geek mode enabled: the band name is even spelled identically, including the bang: https://en.wikipedia.org/wiki/Snap! - Given that Jens Mönig, like the band, is German, here's hoping that the name is a tribute)
There's actually a Snap! disambiguation page on Wikipedia, that includes the Snap! German Eurodance group, as well as the Snap! (album), greatest hits album of The Jam, the Snap! programming language, and SNAP!, a Canadian English-language arts magazine.
I'm afraid the exclamation point was my doing, not Jens's. I was scared of how many other things were called "snap," including the US welfare program that used to be food stamps, and was hoping to stand out from them. Didn't work; I didn't realize that search engines pretty much ignore punctuation.
We were very happy with the name BYOB, but we had a few teachers tell us very insistently that they could never use a language called that with kids. Those of you who live in civilized countries can't appreciate Americans' lack of a sense of humor. So we were looking for a reasonably short name for which the ___.berkeley.edu domain was available, and Snap was what we found.
I feel your pain, I once made a PHP template engine called Farty and needless to say, it didn't take off :-)
That said, I feel a bit dumb right now, but can you (or anyone, really) elaborate what's funny and/or sensitive about the name BYOB? I really can't figure it out. It seems like just an abbreviation to me.
> That said, I feel a bit dumb right now, but can you (or anyone, really) elaborate what's funny and/or sensitive about the name BYOB? I really can't figure it out. It seems like just an abbreviation to me.
Bring your own beer, and since alcohol is Evil™ anywhere even remotely associated with children...
Great. I had read about it but wasn’t sure if it was a better option than Scratch for younger kids. Mine are 6 and 7 and I they use something similar to Scratch. Does anybody know if younger kids use Snap! ?
We have a few who've just shown up on their own, but my friend Paul Goldenberg (my own nominee for best educator) has a project using Snap! with second graders, not to teach programming but to teach mathematics using Snap!-based microworlds.
It looks cool. It reminds me of old-school Flash programming - which also introduced a generation of kids programming in general, because you could make cool games and animations.
It would be really helpful if Scratch would allow projects with multiple scenes. For any moderately involved story or game, there will tend to be multiple scenes or levels. The limitations of a single scene makes it necessary to write many conditional statements to show and hide items or change backdrops when a scene or level changes.
Pretty much. I think "just" is oversimplifying a bit of how powerful they can be, but yes all the reporter blocks are shape generic, and we're exploring whether other tools can be as well. Could we build a really intuitive version of np.vectorize? Maybe. :)
In the File menu inside Snap!, click on libraries and on that list there's an entire APL library that expands upon these ideas. I am no APL expert; this is something really designed more about pushing the limits than something we're actively trying to teach, but there's definitely useful tools in there.
I was lucky enough to meet Ken Iverson and Adin Falkoff at age 14 and have been an APL fan ever since, so the APL library has been a labor of love for me! It still needs a lot of work but it's getting the ideas out there.
The one really terrible thing about the current iteration of Snap (that I think would be trivial to solve?) is that you have to remember to save your work. I don't think that's a normal thing for people to think about on the web in this day and age, and I have seen many students (and my own children) lose large amounts of work due to this. It's extremely discouraging.
Other than that though, the snap language/environment is quite nice.