Discuss Scratch

xly
Scratcher
100+ posts

Snap! user discussion


The main interest of Snap! is not to increase your applis speed, but to increase your brain speed…
Take for example this Jens project :

https://snap.berkeley.edu/snapsource/snap.html#present:Username=xleroy&ProjectName=150-antsandeggs

The interest is not to see ant making quicker its egg heaps, but to understand the making of blocks by Jens the Wizard and then…try to reuse them for your applis in your own way. The challenge is there..

Last edited by xly (Oct. 16, 2017 20:52:01)

cycomachead
Scratcher
100+ posts

Snap! user discussion

bharvey wrote:

Case sensitivity: I strongly disagree. What's “bad programming practice” is having two different things named “foo” and “Foo” in a program. I don't care if C-derived programming languages have case-sensitive symbols. Our raison d'être isn't training future C programmers, or future programmers at all. It's lowering the barriers to entry for kids who want to explore programming.


I think the concern is more about the way equality is handled. I think I agree with you about case-insensitive symbols, but equality comparisons are different and, I think it's reasonable to want to check whether “apple” is different from “APPLE”. Certainly the single character test for “A” = “a” does seem weird to most students I've encountered. (Which makes sense; English treats upper and lowercase letters very differently. With that in mind, Scratch targeting kids as young as ~5 years, I can see this making more sense. But we're targeting 13 and up, where almost all kids have learned the rules.)

As far as “kids who want to explore programming.” We do need to walk the line between ease of use in the present and hindering people in the future.
In general, I think we're far more on the right than wrong with Snap!, but some stuff like case sensitivity does give me pause, but that's also partially because our extreme simplifications cause more problems. (See also colors debates.)

As a more general point about Snap!'s equals function: Abstractions leave rooms for leaky abstractions. We haven't been able to completely remove the distinctions between numbers and strings. There's still plenty of subtle edge cases. Again, on-balance, I do think Snap! (and Scratch) made the right choice, but whenever a student runs into an edge case you either lose their trust or have to teach them stuff they otherwise might not need to know.



Re speed: My biggest feeling with speed is that it's the graphics of drawing things manually – while many programs are compute heavy Snap! (through Morphic) is literally drawing everything by hand. Browsers aren't optimized for this case, where as all the crazy work goes into optimizing all the DOM interfaces and APIs.

When you look at flame graphs of where time is spent, a lot of spent just on the drawing. Even for normal projects. This is why turbo mode works so well – though even then I bet there's room for improvements.
PullJosh
Scratcher
1000+ posts

Snap! user discussion

Re speed: What if an option was added to Snap! that allowed a project to be run without the stage entirely? That way, when working with data/computation heavy projects, there's no need to worry about lag caused by rendering sprites.

That being said, it's quite possible that rendering the regular Snap! gui is just as computation-intensive as rendering the stage. I don't know.

Base 10 is the best number system.
bharvey
Scratcher
1000+ posts

Snap! user discussion

@PullJosh: Isn't that what WARP does? There's no redisplay while warped.

@cycomachead: I would be open to having the IS IDENTICAL TO block do case-sensitive comparison of strings, but I'm not convinced about the appeal to English rules. In the sentence “Easy come, easy go” do you really think anyone believes that the first and third words aren't the same word?

About speed, I think Jens is not going to abandon Morphic. If WebGL would help in Morphic, maybe we might think about that down the road.

bharvey
Scratcher
1000+ posts

Snap! user discussion

Snap! 4.1 will be officially released this Sunday, Oct 22.

v4.1 Features:
* polymorphic sprite-local custom blocks
* inheritance of sprite-local custom blocks
* inheritance of sprite attributes (x, y, direction, size, costumes, costume #, sounds, scripts)
* first-class costumes and sounds
* visual indicator (map-pin icon) for sprite-local custom blocks (i.e. methods)
* camera snapshots for costumes and new sprites
* localization support when typing expressions
* support for user-forced line-breaks in custom block labels
* ternary Boolean slot setting: support to limit Boolean input slots to “true/false” outside of rings and in palette
* support for default values in custom block Boolean slots
* experimental: duplicate block definition (hidden in shift-click context menu)
* support for codification of String, Number and Boolean value types
* costume icons indicate svg costumes
* sprites’s rotation centers can be adjusted onstage
* clones share their original sprite’s scripts, not a shallow-copy of them
* a highlight-colored balloon indicates the number of active processes per shared script
* new musical “notes”, “location”, “footprints”, “cross” and “keyboard” symbols
* new “visible stepping” toggle button in the control bar
* new “keyboard entry” toggle button in the scripts tool bar
* turn on the “Inheritance support” setting per default
* Assert data types to list operations for more meaningful error messages
* programmatically hide and show primitives in the palette
* new “pen trails” reporter primitive and stage context menu entry
* two-item lists as x-y coordinate arguments for “point towards”, ”go to“ and “distance to” primitives
* Piano keyboard as drop-down menu for entering musical notes, Thanks, Michael!
* Basic “instruments” support: sine, square, sawtooth and triangle waves
* Support https in “url” reporter
* splitting csv-text
* prevent context menu and dragging for stage watchers in presentation mode
* ”floating“ search and make-a-block buttons in the blocks palette
* ”Make a block“ button in every category
* experimental ”download script“ feature
* new ”Animation“ library
* new ”Pixels“ library for MediaComp
* double-clicking a corral sprite icon flashes the sprite onstage

Fixes:
* changed keyboard shortcut indicator for “find blocks” to “^”
* prevent Snap from “hanging” when encountering certain errors in visible stepping
* only mark implicit parameters if no formal ones exist
* optimized thread-launch and script highlighting to a single frame instead of formerly two
* changed direction attribute of sprites to automatically confine to 0-360 degrees
* fixed rotation-bug when flipping costumes in ”only turn left/right“ mode”
* fixed variable renaming (“refactoring”) bugs, thanks, Bernat!
* fixed “fill” block crash when applying the same color twice
* fixed occasional empty drop-down menu items named “close”

BookOwl
Scratcher
1000+ posts

Snap! user discussion

support for user-forced line-breaks in custom block labels
How can I use this feature?

Last edited by BookOwl (Oct. 18, 2017 13:08:19)


who needs signatures
BookOwl
Scratcher
1000+ posts

Snap! user discussion

bharvey wrote:

@cycomachead: I would be open to having the IS IDENTICAL TO block do case-sensitive comparison of strings, but I'm not convinced about the appeal to English rules. In the sentence “Easy come, easy go” do you really think anyone believes that the first and third words aren't the same word?
From a semantic standpoint, no, there is no difference.
From a grammatical standpoint, there is a huge difference! The first word starts with a capital, while the second word is all lowercase. You can't swap them around without getting an invalid sentence fragment like “easy come, Easy go”.

Also, the case insensitive comparison doesn't even always work when using non-Latin characters like
"ê" == "ê" // Returns false!
"å" == "å" // Returns false!
"LİMANI" == "limanı" // Returns false!
"BUSSE" == "Buße" // Returns false!
If you are going to get true case insensitive comparisons in Snap!, a proper unicode normalization library will have to be used.

I also prefer the case sensitive equality operator since if you have a lowercase (or uppercase) block and a case sensitive equality block it is easy to get the current case insensitive equality block with
<(lowercase [ABC] :: operators) = (lowercase [aBc] :: operators)>
but it is much harder to get a case sensitive equality block from the case insensitive equality block.

who needs signatures
bharvey
Scratcher
1000+ posts

Snap! user discussion

Line breaks in custom blocks: In the Block Editor, click the plus sign where you want the break, then click title text, then click the downarrow in the text slot, and choose “new line” (at the bottom of the menu).

“Each” vs. “each”: Yes, they fill different slots in the sentence. But that's not the point. Find someone who isn't a computer person and doesn't know the context of this discussion, and ask whether they're the same word or different words. Alternatively, look them up in the dictionary! You'll only find one of them it.

Internationalization: Yes, you're right, it should work in different languages. Feel free to file a bug report. I think the right thing is to compare toLower(toUpper(char)), right? (Has to be in that order because of the ß thing.) (So your version of case-independent comparison based on case-sensitive doesn't quite work either.)

BookOwl
Scratcher
1000+ posts

Snap! user discussion

bharvey wrote:

Line breaks in custom blocks: In the Block Editor, click the plus sign where you want the break, then click title text, then click the downarrow in the text slot, and choose “new line” (at the bottom of the menu).
Thanks!

bharvey wrote:

“Each” vs. “each”: Yes, they fill different slots in the sentence. But that's not the point. Find someone who isn't a computer person and doesn't know the context of this discussion, and ask whether they're the same word or different words. Alternatively, look them up in the dictionary! You'll only find one of them it.
Yes, they are one word, but they are still two different sets of symbols. You wouldn't want a data compressor to get rid of all case distinctions in whatever text you are compressing, would you? Or if you write a cipher in Snap! for learning purposes, you wouldn't want decrypt(encrypt(text)) to be the lowercase form of text, would you?

bharvey wrote:

Internationalization: Yes, you're right, it should work in different languages. Feel free to file a bug report. I think the right thing is to compare toLower(toUpper(char)), right? (Has to be in that order because of the ß thing.) (So your version of case-independent comparison based on case-sensitive doesn't quite work either.)
Doing toLower(toUpper(char)) helps, but still fails on some input. The correct thing (as shown in this SO answer) is to do something like the following Python code:
import unicodedata
def normalize_caseless(text):
    return unicodedata.normalize("NFKD", text.casefold())
def caseless_equal(left, right):
    return normalize_caseless(left) == normalize_caseless(right)
Unfortunately, JS doesn't have anyway to do this without pulling in an external library.

who needs signatures
bharvey
Scratcher
1000+ posts

Snap! user discussion

BookOwl wrote:

You wouldn't want a data compressor to get rid of all case distinctions in whatever text you are compressing, would you?
It wouldn't bother me unless the text were a C/C++/etc. program. You have to bear in mind that I grew up with six bits per character, so lower case letters were a great luxury when they appeared.

Apparently the current Right Thing in JS is localeCompare(): https://stackoverflow.com/questions/2140627/javascript-case-insensitive-string-comparison.

TheAspiringHacker
Scratcher
100+ posts

Snap! user discussion

Couldn't you just use the JavaScript function block to call the JavaScript string comparison?

“…the keynote speaker asked the audience to indicate by show of hands, one, how many people disliked C++, and two, how many people had written a C++ program. There were twice as many people in the first group than the second. Expressing dislike of something you don’t know is usually known as prejudice.” - Bjarne Stroustrup
bharvey
Scratcher
1000+ posts

Snap! user discussion

TheAspiringHacker wrote:

Couldn't you just use the JavaScript function block to call the JavaScript string comparison?
Yes, but are you suggesting that that would be case-insensitive, or that BookOwl should do that to get the case-sensitive comparison he wants?

AlfredThulin
New to Scratch
4 posts

Snap! user discussion

Hi,
I am helping my kids do some coding in Scratch and discovered Snap.
I helped them build a very simplified physics engine with collision resolution in Scratch, but I want to do a rewrite to solve issues, and I am locking for a more “proper” or better way to execute in SpriteX: set CreatedVariableA of SpriteY to Z, without creating global variables.

This was sort of possible backwards in Snap by using the following small program in which the created variable vx had to exist locally in both Sprite1 and Sprite2 for the drop down menu of set to work, and this will set vx of sprite2 to 5.

Sprite1:
set vx to 0
set nx to 5
tell Sprite2 { set vx to nx of Sprite1}

Any idea how to do this otherwise would be appreciated.

Best wishes Mattias





_nix
Scratcher
1000+ posts

Snap! user discussion

Yeah, the variable dropdowns have always been a tough problem (I think?). Basically, the proposed idea is that Snap! detects what the context of that ring (inside of “tell sprite 2 to…”) is, and then sets the contents of variable dropdowns appropriately. But, in practice, there's no way for Snap! to know what context that is – for example, what if you drop “item (random) of (my neighbors)” into the sprite input?

But there's a way to do what you did that's easier – drag out the “set vx to ()” block while Sprite2 is selected, so that the menu item “vx” is selected. Then drag the “set vx” block over Sprite1, in the sprite corral. This will make a copy of the “set vx” block appear inside of Sprite1. So now you can drop the “set vx” block from Sprite2 back into the palette. Then select Sprite1, and you'll see a “set vx” block, which you can drop into your “tell” script.

It sounds complicated, but it's actually faster! This way you don't need to create any “pretend” variables.

(Alternatively, you could drag out a “script variables” block, create a variable named “vx” (by clicking on “a” and renaming it to “vx”), then attach a “set” block, then select “vx” from its menu, then disconnect the “set vx” block and attach that to your “tell” script. Then just get rid of the no longer needed “script variables” block. This might be a little bit faster because you don't need to switch sprites; you do need to type the name of the variable again, though.)

art blog – My pronouns are they/them, btw. sparrows one word to the paragraph
AlfredThulin
New to Scratch
4 posts

Snap! user discussion

Thanks! _nix both ways works to get around having to use pretend-variables.

I should maybe mention that I tried tried without success.

In sprite1:
Launch (Set to 0) with inputs (vx of Sprite2), 10

Did not set vx of Sprite2 to 10, whether or not “vx of Sprite2” was ringified or not.
TheAspiringHacker
Scratcher
100+ posts

Snap! user discussion

bharvey wrote:

TheAspiringHacker wrote:

Couldn't you just use the JavaScript function block to call the JavaScript string comparison?
Yes, but are you suggesting that that would be case-insensitive, or that BookOwl should do that to get the case-sensitive comparison he wants?
I meant the latter.

“…the keynote speaker asked the audience to indicate by show of hands, one, how many people disliked C++, and two, how many people had written a C++ program. There were twice as many people in the first group than the second. Expressing dislike of something you don’t know is usually known as prejudice.” - Bjarne Stroustrup
bharvey
Scratcher
1000+ posts

Snap! user discussion

AlfredThulin wrote:

I am locking for a more “proper” or better way to execute in SpriteX: set CreatedVariableA of SpriteY to Z, without creating global variables.
How do you feel about global procedures? You could just make a SetVX block with an input that does a set. Then you could TELL right?

AlfredThulin
New to Scratch
4 posts

Snap! user discussion

Hi, bharvey.

I tried and have tried things similar to that (I think). Possibly it can be made to work, but at least it flies over my head how to do it in practice.
I will do the rewrite by letting SpriteA use velocities and position of the SpriteB, with which it has collided, to calculate both its own new velocities and SpriteB's new velocities. Then Tell SpriteB to Set its x,y,vx,vy variables from the calculated-update-variables in Sprite1 that would be nx,ny,nx,vx.

AlfredThulin
New to Scratch
4 posts

Snap! user discussion

Typos. Last part should read nx,ny,nvx,nvy
bharvey
Scratcher
1000+ posts

Snap! user discussion

Snap! 4.1 is now installed.

The manual is almost ready.

@AlfredThulin: Going crazy with two deadlines at once, sorry; I'll get to your message shortly.

Powered by DjangoBB

Standard | Mobile