Snap Programming Language Download
Sharon Harris
Snap! (formerly Build Your Own Blocks) is a free block-based educational graphical programming language and online community. Snap allows students to explore, create, and remix interactive animations, games, stories, and more, while learning about mathematical and computational ideas. While inspired by Scratch, Snap! has many advanced features. The Snap! editor, and programs created in it, are web applications that run in the browser (like Scratch 3) without requiring installation.[Note 2] It is built on top of Morphic.js,[2] a Morphic GUI, written by Jens Mnig as 'middle layer' between Snap! itself and 'bare' JavaScript.
In Snap!, the screen is organized in three resizable columns containing five regions: the block group selector (top of left column), the blocks palette (left column), the main area (middle column), and the stage area (top of right column) with the sprite selector (also called the sprite corral) showing sprite thumbnails below it.[Note 3]
In the interactively resizable stage area are shown the graphical results of the scripts running in the script area and/or interactively double-clicked individual blocks in any palette. Individual blocks can be dragged from the palette onto the scripts area to be associated with the selected sprite.
Alonzo, the mascot of Snap!, bears the name of Alonzo Church, the inventor of a model of computation in which a universal function, represented by lambda, can create any function behavior by calling it on itself in various combinations. The mascot is a modified version of Gobo from Scratch, with permission of the Scratch team. Because Alonzo Church's work is called lambda calculus, the mascot's hair is shaped as the Greek letter lambda.
Many other libraries are available, such as the 'list utilities' library, the 'words, sentences' library, the 'iterations' library, the 'animation' library, the 'frequency distribution' library, the 'audio computation' library, the 'bar charts' library, the 'world map' library, the 'colors and crayons' library, the 'strings and multi-line input' library, the 'parallelization' library, etc. for other special purposes.
The web-based Snap! and older desktop-based BYOB were both developed by Jens Mnig for Windows, OS X and Linux[3] with design ideas and documentation provided by Brian Harvey[4] from University of California, Berkeley and have been used to teach "The Beauty and Joy of Computing" introductory course in computer science (CS) for non-CS-major students.[5] Jens was a member of the Scratch Team before creating Snap!.[6] BYOB is still available for downloading.
The source code of Snap! is GNU Affero General Public License (AGPL) licensed and is hosted on GitHub.[7] The earlier, desktop-based 3.x version's code is available under a license that allows modification for only non-commercial uses and can be downloaded from the UC Berkeley website[8] or CNET's download.com and TechTracker download page.[9][10]
All things visible in Snap! are morphs themselves, i.e. all buttons, sliders, dialog boxes, menus, entry fields, text rendering, blinking cursors etc. are created with morphic.js rather than using HTML DOM elements. Snap! caches the shapes of sprites so the sprite doesn't have to be re-drawn onto a new Canvas element every time the mouse moves over its bounding box. It does not cache blocks, however. Instead it manages the insides of C-shaped blocks through the morphic "holes" mechanism.
All user interaction is triggered by events, which are passed on from the root element "the world" to its submorphs. Dropping a morph causes it to become embedded in a new 'owner' ('parent') morph. In Morphic the preferred way to run an animation is to register it with the World by adding it to the World's animation queue. The World steps each registered animation once per display cycle independently of the Morphic stepping mechanism.
I noticed that on the new website there are translations available and some information is available in several languages, but not all. (E.g. the Extensions-Site is English-only)
Also Images aren't available in e.g. German versions.
Since I am teaching at a German school, I consider it important for my younger students to be able to use Snap*!* fully in the German language. Now there are still quite a view e.g. buttons not translated on both the website and the programming environment/ide.
E.g. on the website: "My Projects" instead of "Meine Projekte"
E.g. in the IDE: Buttons "Unshare" instead of "Freigabe aufheben"; the fields in the sign-up dialog.
Also are there plans to flag projects with a certain language, so that e.g. German users could filter the published projects (at least for language sensitive projects). Maybe even set their language skills in their profile?
My TODO list is long, and making the site easier to translate is somewhere in there. You can go ahead and use this file for now, and I promise your translation won't be steamrolled if I ever get to have time to make the system better.
I noticed that Italian accented chars are not rendered as they should. For example the "" is replaced by a question mark. Is there a way to make those chars correctly appear in the website? Should I escape them or else?
Hi there!
I don't know if I should post here but I think I can help with a translation in French which is a language that is quite important to me, I am French. I'm also a Scratch user and I don't know how I can help translating. I saw that you have an organization on the Transifex site, a site for translate, but I think it is inactive...
Read this file: CONTRIBUTING.md (9.1 KB)
The first part is about adding code to Snap! itself, but toward the end is the part about translating. It will tell you what to do. By all means, if something isn't clear, ask about it here.
Hello!
I've revisited the programming universe at greater length and there are no mistakes, except maybe one or two to review... but there are some blocks that are not translated, I'll see if I can try to help you with that but I think that translating the most important pages of the site is important because it's what the visitor sees first and I see what I saw first.
When it's in the language you speak it makes you want to go programming on Snap and get interested in it so I think I'll do what you said last to try to help with the translation of the site.
Nice day!
i dont want to say say it but, snap is dissapointigly slow. its like every time i really start to get somewhere in a project it gets so laggy its basically useless. im sure theres plenty of optimizations that i could be making but ive been spending alot of time trying to redo what ive already done, and im starting to think its just snaps limitations.
Wow. Nice project! But you gotta watch out what you compare. When I look at your Scratch code there are hardly any abstractions in there, all is written out and even copied verbatim a lot. Such code looks ugly but runs fast. On the other hand if I look at this block of yours:
it's clear why your Snap! code is slow, especially since you're constantly calling this block 4 times in a row! What's the idea behind this architecture even? Why are you defining a "test" variable and assign it a new (!) ring every time the block gets invoked? Of course that's terribly inefficient. You're not doing the same in Scratch are you?
haha that's what I call 'its almost time for work and I still haven't figured this out yet' code. it's not uncommon I just end up throwing pieces together just to see what happens, especially when I'm getting frustrated. I mustve done something right because that block wasn't originally part of the code and I didn't even realize I saved it in that state but yet somehow you've found sense in my ridiculous test variable set up and (im assuming) solved my problem. I'll have to check it out when I get home tn from work but I'm pretty intrigued to see what you've done.
I do this when the subroutine is only of use in the block definition and that block needs to call to it from multiple places. It seems wrong to clutter up a project by making the helper function into a globally accessible block.
Remember that the anonymous function is created new every time you call the block (because it's assigned to a temporary variable), rather than just once when you define it as a permanent block. This makes it very inefficient in situations that rely on rapid successions of running the block inside an animation loop.
I think there's a classic teachable moment here about the tradeoff between expressive elegance and execution efficiency. Expressive abstraction is wonderful, because it dramatically speeds up development turnaround. You get much more done in a shorter time. Or, as my favorite LISP song says "God had a deadline, so he wrote it all in Lisp" (Eternal Flame - GNU Project - Free Software Foundation).
Code that runs fast is often full of optimizations that are hard to understand, repetitive, and terrible to maintain. To make something run fast the secret is to literally make it "do less". Often that involves more code that ends up doing less than elegant code. For example, using a variable to remember the result of a function, so you can just reuse what you've already computed before instead of calling the function again is the secret of all caching. This gets to be very complicated very quickly, because you're introducing state to what used to be "pure", and you'll need to write more code that figures out when to invalidate the cache. Suddenly there are a lot more places where things can (and will!) go wrong, that have side effects you didn't consider and bugs that have nothing to do with the feature you're working on. And - worst of all - you'll have all the mathematician hotshots snickering at your oafish, clumsy code. But when it's all working it'll be super fast, albeit very hard for others and your later self to build upon.
Hardcore "game" devs will likewise snicker at the highlevel programming languages, claiming that their allegedly "simple" imperative ones are much more efficient and "faster" than those highfalutin' scripting ones. Their code will be full of things like a giant "game loop" in which they'll explicitly poll for the state of individual keys instead of listening to events. They'll use lots of global variables to cache state that different parts of what looks like spaghetti code all access, and you're going to have a hard time dissecting where in code which feature is defined, because it'll all be intermingled into one big mesh.
c80f0f1006