Ok, I see your point. Thinking about it this way, I agree with you. I was xferring my project into Snap for testing the key press stuff but remember how you can accomplish scroll detection in Scratch. Snap!'s way is actually much better for code readability etc. (semi-off topic question: If I wanted to help w/ making Snap! more like how Scratch was meant to be (like how its not suppose to detect mouse wheel events like that), where should I go? Is there such a place? Still very new to Snap!)
I'm not sure what you mean by "how Scratch was meant to be." But if you're new to Snap!, I think the first thing you might do is look at some of the libraries written in Snap! itself, such as the List Utilities library, the Iteration and Composition library, or the Words and Sentences library, then find something you think is missing and see if you can implement it.
1 Like
You keep talking about it. Just do it. 
At this point in time, Snap!'s primitives are similar enough to Scratch's that there's no reason you shouldn't be able to open Scratch projects in Snap!. Most Scratch projects can be recreated in Snap! without changing much, if anything. The work Snapinator does is mostly a matter of converting between the relevant data structures so that kids don't have to go through the drudgery of doing it themselves.
Of course, if you want to take advantage of Snap!'s features, you're going to have to rework the project, but Scratchers are used to reworking things. Scratch's entire culture is built on allowing kids to create and remix projects, and I think there's great value in making all 60 million Scratch projects available as a base for remixes in Snap!. Maybe you haven't seen any Scratch projects you'd find worth extending with Snap! features yet, but there are 60 million Scratch projects. There's bound to be something you would find worthwhile in there.
Of course, if Snap!'s primitives were sufficient different from Scratch's, it would be a different story. But we aren't at that point yet, and we'll cross that bridge when we get there.
ok, now, I think it would be great if there was something like
[scratchblocks]
when [up arrow v] pressed or [scrolled up v] :: control hat
[/scratchblocks]
Just use a key pressed hat and when scrolled hat that trigger the same broadcast or custom block. This doesn't need its own primitive.
Well, there's the small matter of getting Jens to agree. He's much more tied to Scratch in his thinking than I am. That's why we have video capture with motion detection, for example. Also, we can't do it a little at a time, because we don't want to break our own existing projects, so we have to increment the version number in project files and continue to support the old ways when loading old projects, and Jens is right that that sort of thing leads to ugly code. And we have to coordinate with you, so that Snapinator can translate Scratch projects into the new ways of doing things. (https://en.wikipedia.org/wiki/Flag_day_(software))
There's a chicken and egg problem; you're saying when we get different enough we can worry about whether we want to get different. And you're right that I'm having trouble getting anyone, not just Jens, to entertain that idea in the abstract, but if they don't, it'll never happen.
And then there will be sub-disagreements on the details. For example, I really want to replace the existing pen color primitives with my color library (reimplemented in JS). I think Jens is quite happy to have the library, but would resist replacing the primitives with it, partly because he doesn't believe in HSL, partly because that isn't how Scratch does it, and partly because it's just more complicated. (I think it doesn't matter that it's complicated, because the complication is just while running SET PEN. Once you've done that, you have an RGB color under the hood and it doesn't slow down drawing at all.
My suggestion is to make [how the the primitives handle units] line up with how the "real world" does things wherever possible, and make all the Scratch-isms and other abstractions like crayons into library blocks. That includes directions and color. Whenever an old project with Scratch blocks is loaded, load the Scratch-isms library, and replace all the old primitives with the library blocks.
It's usually quite a bit easier to find information on how to work with real world conventions than with whatever poorly explained, magic systems the Scratch Team's decided on. Like, I think as long as there's a block to set the pen color's R, G, and B components, figuring out how to do different color systems is pretty trivial. Assuming performance isn't too big an issue, the other color systems, including Scratch's, could be implemented entirely in Snap! to act as an example of that.
Ah, no, you don't really mean that (I hope). For example, the real world doesn't do turtle graphics; they make you figure out the Cartesian (but with the Y axis upside down) coordinates of the endpoints of the line segment you want to draw. Sprites, costumes, all those things are abstractions built on top of real world capabilities.
The question is, what abstractions make it easiest for a learner to express their goals with a minimum of arcane incantations.
Actually, even the real world uses abstractions. For example, take crayons. The real world uses crayons! You can say "color:powderblue" and get b0e0e6. And my color library includes the X11 crayons as an option, although I like my crayon selection better because it's more evenly distributed through color space. (They have 20-odd off-white colors, for example: ghostwhite, oldlace, snow, ivory... They probably started by looking at a sampler of house paints.) Even more important, my crayon block has a two-level menu in which the colors are divided into their spectral families, so you don't have to search for the color you want.
But also, much of the time people don't care about the exact colors; they just want to be able to say change color by 1 and get a more or less continuous gradation of interesting colors. That was a good abstraction in Scratch, which they've moved away from by making the HSV scales explicit. (The old way did have the misfeature of getting trapped in black.) My default color scale restores the one-dimensional scheme while avoiding the black hole and including shades of the spectral colors.
Now, there's plenty of room for argument about whether the abstractions I've chosen are the best possible. But certainly RGB isn't the best answer! And HSV is probably the worst possible because of its asymmetrical treatment of tints and shades. I would love to have the argument with people interested in colors, and maybe you could convince me, for example, that we should use the X11 crayons rather than mine for real-worldness.
Similarly, the real world, at least the real world of computing, doesn't use polar coordinates in graphics. They only use the upside-down Cartesian coordinates. So both the Scratch clockwise-from-north and the mathematical counterclockwise-from-east are abstractions. The original Logo approach, which Scratch inherited, was that kids intuitively see north as the "starting" direction because they see both actual compasses and the privileging of north in the compass rose on a map:
(which is that way, of course, because on a magnetic compass they paint the north-facing end of the compass red). I think that was definitely the right choice in Logo. In Scratch it's complicated, because most of their costumes, the ones representing people anyway, are vertical and facing east, so they end up giving sprites a starting direction of 90. That's a needless layer of confusion for beginners. For us, it's further complicated by the fact that our audience includes math teachers, who are adamant about ccw-from-east. Their reasons have nothing to do with what's intuitive for kids, so the question for us is whether we care enough about mathematical convention to adopt it -- well, that and the argument that costumes start out facing east.
That question, about measuring direction, is one that Jens gets angry about. He points out that it's trivial to write a library with blocks ANGLE and SET ANGLE that do ccw-from-east. And he's right. So the First Law of Engineering tells us not to change how we do it. I think if we implement student accounts and implement per-user startup libraries, I would then be totally in favor of not changing DIRECTION.
Anyway, the point of this long message is really just that you can't say "do what the real world does" in a language for learners. Otherwise we'd just teach Javascript instead, or anyway make the Snap! blocks exactly represent the JS primitives.
Oh, I do, but not in the sense of getting rid turtle graphics. That would be silly.
I mostly mean it in the context of units - a lot of primitives accept numbers, but what do they actually mean? The "real world" often doesn't agree how things should be measured (insert grumbling about the US and metric here), but I think it's important to use a method used somewhere in the real world, so that users can find some sort of information on how to work with the numbers put in front of them.
My view on Scratch directions is that putting the start direction at 90° is plain confusing. If you have a costume of something facing right, 0 = NORTH, and it makes sense, but as soon as you have a costume of anything else, that breaks down. I'm not aware of any other context where 90° means "no rotation." Whether positive means cw or ccw, I don't care so much.
The old Scratch pen colors were the worst. For one, they used (and still use) the word color instead of hue, hues ranged from 0-199 for some reason, and there were these mysterious "shades" that I still don't understand. Want to use a color picker from an "adult" program that gives you an RGB/HSV/HSL/whatever? Good luck with that.
RGB is definitely not the best abstraction for general use, but I think it should be available since it's widely used, and it's easy to find information on its relationship to better abstractions. And it would be great if the better abstractions that Snap! provides are written in Snap! itself so users can see how they work, instead of them being inaccessible magic.
One of the Scratch abstractions that upset me recently, which you've probably already seen, is pitch. First, the pitch blocks use tenths of a semitone, which is just weird, and second, they don't even make the units visible. I guess you're just supposed to type in a number that sounds good, but I'd prefer to be able to tell what's going on, and read up on how it works.
For the most part, the Snap!-specific features do a good job with this. The sound blocks are labeled with Hz, it's explained where character codes come from, the crayon names have hex codes next to them, etc. That's all good, but I think there's still room for improvement on the features inherited from Scratch.
Anyway(s), sorry for not being explicit enough in the first post, and I hope this clear up what I meant.
Oh, yes, 0-199 is weird. What's good about the (old) Scratch color abstraction is just that it's one-dimensional. You can say change color by 1 and expect something sensible to happen.
A shade is a mixture of a spectral color (hue) with black. In color transmission (monitors, as opposed to paints or dyes), that means reducing the intensity of the hue, because there's no such thing as black light to mix in. If you mix in white instead, you get a tint.
Of course RGB should be available. My set color block even accepts six hex digits! The question is, what should be the default choice when you drag the block out of the palette. Certainly not RGB, and I think not hue (our current status) either. My choice, a color scale that goes through the spectrum but also includes shades (darker versions) of the spectral colors, is admittedly three levels of abstraction up from RGB (hue, fair hue, color), but someone who cares about color in detail has a complete choice of all possible scales. The color abstraction is meant entirely for users who really don't care about the colors as long as they're different, and continuous. (That latter requirement is why crayon shouldn't be the default scale.)
(The crayon menu, by the way, should also have color samples!)
So, the meta point here is to think about whether it matters what metaphor about colors you show to users by default, given that you offer all the other possibilities too. I think it does matter. Jens, I think, thinks (at least with respect to colors) that it doesn't matter.
Whether it matters has to be settled before you start thinking about what the best choice is.
To be honest this place is slowly fading away because of Scratch, maybe Snap! should use some original features, not only just Scratch features?
I know I made some feature requests that have a Scratch feature, but that was mainly for the Costume Editor and not just because "Scratch has it" I simply just wanted a good Editor tool that can be easier for me and other young Snap! coders to make a very detailed drawing!
To be honest it kinda annoys me when people need something on a website just because another site has it, they should create their own things(The things that make them unique).
Also, if you want a feature that is only on Scratch, just go to Scratch and do the coding and stuff, and then use the Snapinator to publish your work on scratch here!
People should stop trying to make Snap! an exact copy of Scratch.
Sorry if I made my opinion a little random, but I read the conversation between @bh and @djdolphin, and I had an opinion stuck in my head that I just had to get out and tell all of you. This isn't Scratch, and Snap! shouldn't be an exact copy of Scratch....thank you for reading my comment. And please don't be mad at me for my own opinion, this didn't take forever to type just for you to get mad at me.
I know what a shade is in the abstract, but Scratch shades were just not implemented in a way where the numbers made any sense to me.
I've just looked at the source code, and I guess a shade of 0 was supposed to get you 5/6 of the way from hsv(hue, 100, 100) to black, a shade of 50 is just hsv(hue, 100, 100), and a shade of 100 was supposed to get you 5/6 of the way from hsv(hue, 100, 100) to white. Even understanding what's going on, it's just rather arbitrary.
In the grand scheme of things it probably doesn't matter much as long as the units are clear, and it's easy to convert between representations.
Converting anything to HSV is a pain, so I think there should at least be RGB primitives that a color library can use instead of JS.
Of course not. I agree.
1 Like
Thank you! I just needed to get the word out, Snap! should be more unique and people should stop feature requesting things that Scratch has just because Scratch has it, they should have other reasons to have it other than that.
Yes, I know Snap! is supposed to be like Scratch, but Scratch is slowly taking over Snap! little by little, and then I stop and think; "why can't Snap! have its own features, more things that are unique to its own website, and not just Scratch's features?".
Snap! has plenty of unique features. I think the unique features well outweigh the Scratch ones at this point.
Scratch has always been an inspiration for Snap!, so it's not really taking over. When Snap! does differ, it's usually because the Scratch feature has some strange behavior that Snap! hasn't implemented, or because the Scratch feature is easy to recreate with Snap! blocks.
So I agree on the principle that Snap! should be unique, and that it doesn't need most of the Scratch features that are requested. Not the point that it isn't already unique. 
I think you don't know the history well enough to say that. I'm not trying to put you down; you can of course say anything you want, but we started out (with BYOB, the earlier version) actually modifying the Scratch source code, so we were exactly like Scratch apart from a few new ideas. (New to Scratch, not new to computer science.) I think the important thing we showed is that just one new idea, if it's well-chosen, can generate a world of possibilities. Namely, our idea was procedures as first class data. That's what the grey rings are about. With that idea, we could generate new control structures such as FOR and FOR EACH and MAP.
Not that anyone would do this in practice, but it turns out that if you have grey rings and CALL, and nothing else, you can invent numbers and lists and all the arithmetic operators!
The Scratch Team knew all this as well as we did; they just didn't (and still don't) think first class procedures are important for their audience. Eventually we stopped trying to convince them and just went our own way. Since then we added sprite inheritance, hyperblocks, and a bunch of other things not in Scratch.
It's not a big surprise that someone who just recently discovered Snap! after having learned Scratch thinks first about Scratch features when asking for things. I think I vaguely remember a certain person asking for missing Scratch features in the costume editors. :~) Eventually, people learn what makes Snap! special.
One thing I recommend to new users is to look at the Examples projects you can get to from the Open dialog, with the big Examples button on the left. Don't just run them; read the code. That's a quick way to learn about some of our unique capabilities.
I asked for a missing feature from Scratch for the Costume editors (the zoom ability) here, you already saw it!
Ok. I'll check that out. I meant like how, for example, the key pressed hat block is not supposed to detect mouse events, btw.
Definitely want those angle issues fixed. My scratch project actively deals with them. (Yeesh :P)