Snap! 6 is here, and it's all about scale | Hacker News Reader

Snap! 6 is here, and it's all about scale

snap.berkeley.edu

148 pointsrutenspitz58 comments

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.

Autosave is not exactly trivial, but it's definitely on the list. I do agree it's something incredibly useful!

(Doing it right also can incur some costs, and that's something we would need funding for...)

Local storage might be a lifesaver here. Just in case someone forgets to save offer auto recovery. This can be done client side with no server costs.

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.

Thanks. Would you say you need more contributors? And if you do what are you needing? Coders? Project Managers? Designers? Writers?

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.

Yeah as a beginner at open source contributing (but not development) I'd be looking to fix tiny bugs first anyway!

Good point, I was definitely too flippant about the amount of work involved. Glad to hear it's on the list though!

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!

https://ntls.info/ntls-educational-leadership-award/brian-ha...

>[...] 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.

https://en.m.wikipedia.org/wiki/Brian_Harvey_(lecturer)

Wow, thanks! My own opinion is far less extreme. :~) But I definitely appreciate hearing yours.

Learning Scheme and SiCP from him in CS61A was my best experience in college. Pity it happened first semester freshmen year ;-)

Kind of unfortunate CS61A is now Python.

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.

Very well deserved, Jens is an awesome person.

I can second that. The code of Snap! itself is virtually all Jens. My main contribution was teaching him about lambda.

You're awesome too Brian! Didn't mean to be exclusive, I know just know Jens better from SIGCSE.

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

https://www.youtube.com/watch?v=K1qR4vTAw4w&ab_channel=JensM...

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:

https://forum.snap.berkeley.edu/uploads/short-url/a5eBP71x50...

Regarding the link:

> Oops! That page doesn’t exist or is private.

Ah, here's a link to the Morphic2 architectural changes that should work: https://drive.google.com/file/d/1QD-tqtTL3ldtmtqmViNm-C7TW0n...

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. :)

“Snap! is Scheme disguised as Scratch.” -Brian Harvey

btw do people transition out from snap! ? do they go emacs ? vi ? <big>IDE ?

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.

[1] https://tic80.com/

[2] https://github.com/nesbox/TIC-80/wiki

[3] https://github.com/nesbox/TIC-80/wiki#special-functions

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.

All correct! That's pretty much it!

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.

https://www.youtube.com/watch?v=0_x5zsuu5jY

Note: it's not related to the package manager.

https://en.wikipedia.org/wiki/Snap_(package_manager)

Alternately:

Note: it’s related to the visual programming language.

https://en.m.wikipedia.org/wiki/Snap!_(programming_language)

Or with full snark mode enabled:

Note: it’s about the visual programming language (2009) and not the package manager (2014.)

Surely you must mean,

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.

https://en.wikipedia.org/wiki/Snap!_(disambiguation)

https://en.wikipedia.org/wiki/Snap%21

https://en.wikipedia.org/wiki/Snap!_(album)

https://en.wikipedia.org/wiki/Snap!_(programming_language)

https://en.wikipedia.org/wiki/SNAP%21

I think the Object Oriented version of Snap! should be called "Snap! Snap!" instead of "Snap!++".

Great minds snap alike! (That man's nuts: grab 'em! Woo hoo!)

https://www.youtube.com/watch?v=Z8xmQDpYGYo&t=1m38s

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.

Thanks. Sounds interesting. Will google it.

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.

This seems like really nice software.

It's a pity that Scratch seems to innovate at a very slow pace - Snap is far ahead of Scratch.

If you are interested in teaching kids to program I can highly recommend Construct 3 and also Code Combat.

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.

Interesting that you should mention the idea of scenes, just as we've begun working on them in Snap!

Very cool! Here is a bit more context about the idea/need:

https://github.com/LLK/scratch-gui/issues/1907

Jens wants to do that in Snap! as the next big feature.

The description of Hyperblocks leaves much to be desired. Are they just shape-generic blocks?

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. :)

Now I am intrigued. Checking it out in detail tonight.

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.

We have gone a long way from Logo turtles graphics.

Reply on news.ycombinator.com