[yjftsjthsd-h]

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

[moenig]

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

[jdmichal]

Regarding the link:

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

[moenig]

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

[cycomachead]

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

[DonHopkins]

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

[agumonkey]

S3

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

[dvdkhlng]

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

[cycomachead]

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.

[bharvey]

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.

[CyberDildonics]

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.