51–60 of 118 posts
> inviting My first attempt to place a statement (play sound at Hz) failed with a Type Error. Android Chrome.
It's an odd quirk of Snap that they never cleaned up. Some blocks have a "friendly" error message. Delete a variable and uses of it get "Hmmm... a variable of name 'name' does not exist in this context". That one just regurgitates the JS error when it should say "You need to add and select a sound to play a sound".
Earlier quoted context omitted.
It's an odd quirk of Snap that they never cleaned up. Some blocks have a "friendly" error message. Delete a variable and uses of it get "Hmmm... a variable of name 'name' does not exist in this context". That one just regurgitates the JS error when it should say "You need to add and select a sound to play a sound".
Nor does it let me select a sound. The drop-down list is empty.
Earlier quoted context omitted.
Nor does it let me select a sound. The drop-down list is empty.
You have to add one, in the sounds tab you can record one, or in the file menu they have a library of them you can load (they also have libraries of sprites and backgrounds which are pretty useful when we use this with students).
Earlier quoted context omitted.
from someone who can remember how they even got into programming: 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?…
Fair that your path worked differently for you. 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, translati…
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
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'.
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.
Snap is designed to be more expressive and powerful than Scratch. But I find debugging them is very painful. Changing the name of a variable or block for example, could create “holes” in the calling sites but the system can or cannot report an error and fails silently. Snap is IMO more flaky and the team seems more eager to add features than polish the existing ones or make the system mor robust and stable.
They've fixed surprisingly many of the quirks, but my biggest gripe with Snap is that they don't like to add documentation with new features. A lot of the older content has a nice "help..." context menu option with a description of what it does (which is often out of date itself, e.g. the "split" and "join" by blocks feature isn't shown on those blocks), and newer blocks have the context menu option... but nothing po…
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.
Any name that you can't type is going to be a problem.
For those wondering the difference with scratch, it's on the about page: > 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 a…
Scratch already allows you to create custom Blocks and features lists. This seems like a perfect example of reinventing the wheel (and fragmenting development communities).
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).
Welcome to the esoteric church of functional programming! 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 compu…