Discuss Scratch

TruDev
Scratcher
80 posts

Snap! user discussion

bharvey wrote:

Our development is independent from Scratch. I can't imagine Jens ever abandoning Morphic!

Well, Morphic was abandoned by the ST about 4 years ago, so why did Jens port it to JS? If Morphic were better, the ST would have ported it to Flash. Also, We should do a Snap! (Morphic.js) vs. blockly efficiency test.

If you have a project you think will be generally useful, sure. People have done it. But if you're just pining for a social-media site, it's coming, likely this summer if the back end mods are on schedule.

Great!

What, you went two minutes without an answer and you're feeling neglected?

No, I just wanted to make Snap! more popular by using a bump.

Since beginnings of 1.4, three accounts so far

TruDev
Scratcher
80 posts

Snap! user discussion

Also, I had an idea…

bharvey wrote:

Chibi-Matoran wrote:

Am I able to restrict the scope of an upvar to the custom block?
Can I have a variadic sequence of tokens in the custom block?
Short answer: no and no.

The scope of an upvar was one of the arguments Jens won. His view is that an upvar is a kind of script variable, and so its scope extends to the end of the script in which it appears. He compromised by agreeing that a later declaration of a script var/upvar with the same name makes a new, distinct variable, which is important if you export a lambda using the upvar.

As for a variadic grouping, we both want that, but haven't worked out a notation we're happy with. One of those things on the “after OOP is done” list.


(variadic grouping ((a↑) = (b) ...) :: grey stack) :: control hat //sorry about the red, didn't cooperate
where a and b would be lists of inputs. But a list of upvars…?

Since beginnings of 1.4, three accounts so far

djdolphin
Scratcher
1000+ posts

Snap! user discussion

TruDev wrote:

Well, Morphic was abandoned by the ST about 4 years ago, so why did Jens port it to JS? If Morphic were better, the ST would have ported it to Flash. Also, We should do a Snap! (Morphic.js) vs. blockly efficiency test.
Here are Jens' old blog posts about morphic.py and morphic.js, which provide some explanation. Probably the most important part:
What’s unique about Morphic? Three things:
  1. It’s a programming language independent mechanism for modelling concurrency. You don’t have to use native threads and processes in order to create lively, interactive applications. Just look at Scratch!
  2. It doesn’t use any OS-native widgets. You get to do what you really want, not what some industry standard thinks is cool. Again, take a look at Scratch!
  3. It’s easily portable. Okay, this is really the essence of the first two points: Because you neither use Smalltalk processes nor Smalltalk’s dependent-update mechanism, nor any OS-specific widgets, your application can easily be ported to both any other programming language as well as any other OS.
Personally, Morphic does make Snap! much easier to modify than Scratch. I don't completely like the canvas implementation though because it's an accessibility nightmare, and it requires weird hacks to get things like copying and pasting and file importing working.
bharvey
Scratcher
1000+ posts

Snap! user discussion

TruDev wrote:

Well, Morphic was abandoned by the ST about 4 years ago, so why did Jens port it to JS? If Morphic were better, the ST would have ported it to Flash. Also, We should do a Snap! (Morphic.js) vs. blockly efficiency test.
If there were one right answer to any engineering design decision, engineers wouldn't be paid so much – and would probably have been replaced by computers already.

For example, at the time the ST decided to use Flash, it was already clear, including to the ST, that in the long run Flash was a dying technology, but HTML5 at that time had essentially no support for generated (as opposed to imported) sound, so couldn't support the Play Note block, nor for access to the microphone and camera, and they felt multimedia support was a do-or-die feature for Scratch. But our focus was and is more on teaching core computer science ideas, and so Jens was willing to take a step backward on multimedia in order to end up with an implementation that would last a lot longer. (It's also relevant that Scratch has a lot of money to support a paid development team, whereas Snap! is one person's unpaid spare-time project!) We all knew HTML5 would catch up eventually. (And meanwhile we get to go to Scratch conferences and show off Snap! running on iOS devices. )

Honestly, I have the same frustrations as djdolphin about copy-paste (and the related inability to use browser extensions such as Password Hasher in Snap!) and screen-reader compatibility. But Jens argues convincingly that the way DOM widgets interact with each other doesn't adequately support the behavior we want with respect to overlapping widgets and other subtle but important aspects of the Snap! user interface. This is what I mean about no one best solution. (If there were one best solution to engineering problems, nobody would program in any language but Scheme. And if authority figures always picked the best solution, nobody would use Windows.)

As for efficiency, the most relevant measure is that Jens is most efficient in Morphic, because he loves it. (See note earlier about a spare-time project of a single developer.)

P.S. Jens has long since gotten tired of having this argument about Morphic, which is why I'm replying instead of waiting for him to do it. So, as djdolphin says, if you really want to get into the details, you should look up what Jens wrote back in the early days.

bharvey
Scratcher
1000+ posts

Snap! user discussion

TruDev wrote:

(variadic grouping ((a↑) = (b) ...) :: grey stack) :: control hat //sorry about the red, didn't cooperate
where a and b would be lists of inputs.
What would this look like in the palette?

djdolphin
Scratcher
1000+ posts

Snap! user discussion

bharvey wrote:

But Jens argues convincingly that the way DOM widgets interact with each other doesn't adequately support the behavior we want with respect to overlapping widgets and other subtle but important aspects of the Snap! user interface.
What sort of aspects?
saofan123
Scratcher
47 posts

Snap! user discussion

why is it licensed under the agpl instead of the gpl?

also, where can i download the source code of byob 3.1.1

Last edited by saofan123 (June 18, 2017 11:28:11)

TruDev
Scratcher
80 posts

Snap! user discussion

bharvey wrote:

If there were one right answer to any engineering design decision, engineers wouldn't be paid so much – and would probably have been replaced by computers already.

For example, at the time the ST decided to use Flash, it was already clear, including to the ST, that in the long run Flash was a dying technology, but HTML5 at that time had essentially no support for generated (as opposed to imported) sound, so couldn't support the Play Note block, nor for access to the microphone and camera, and they felt multimedia support was a do-or-die feature for Scratch. But our focus was and is more on teaching core computer science ideas, and so Jens was willing to take a step backward on multimedia in order to end up with an implementation that would last a lot longer. (It's also relevant that Scratch has a lot of money to support a paid development team, whereas Snap! is one person's unpaid spare-time project!) We all knew HTML5 would catch up eventually. (And meanwhile we get to go to Scratch conferences and show off Snap! running on iOS devices. )

Honestly, I have the same frustrations as djdolphin about copy-paste (and the related inability to use browser extensions such as Password Hasher in Snap!) and screen-reader compatibility. But Jens argues convincingly that the way DOM widgets interact with each other doesn't adequately support the behavior we want with respect to overlapping widgets and other subtle but important aspects of the Snap! user interface. This is what I mean about no one best solution. (If there were one best solution to engineering problems, nobody would program in any language but Scheme. And if authority figures always picked the best solution, nobody would use Windows.)

As for efficiency, the most relevant measure is that Jens is most efficient in Morphic, because he loves it. (See note earlier about a spare-time project of a single developer.)

P.S. Jens has long since gotten tired of having this argument about Morphic, which is why I'm replying instead of waiting for him to do it. So, as djdolphin says, if you really want to get into the details, you should look up what Jens wrote back in the early days.

I already knew the “more than one solution” stuff, I was just wondering about this solution. Snap! may have its differences from Scratch, but Snap! will always be cool.

djdolphin wrote:

Here are Jens' old blog posts about morphic.py and morphic.js, which provide some explanation. Probably the most important part:
What’s unique about Morphic? Three things:
  1. It’s a programming language independent mechanism for modelling concurrency. You don’t have to use native threads and processes in order to create lively, interactive applications. Just look at Scratch!
  2. It doesn’t use any OS-native widgets. You get to do what you really want, not what some industry standard thinks is cool. Again, take a look at Scratch!
  3. It’s easily portable. Okay, this is really the essence of the first two points: Because you neither use Smalltalk processes nor Smalltalk’s dependent-update mechanism, nor any OS-specific widgets, your application can easily be ported to both any other programming language as well as any other OS.
Personally, Morphic does make Snap! much easier to modify than Scratch. I don't completely like the canvas implementation though because it's an accessibility nightmare, and it requires weird hacks to get things like copying and pasting and file importing working.

I know that Jens works better in Morphic, but then why did the ST abandon it? If it's so easily portable, why isn't there a Morphic.swf somewhere in Scratch? Was it too hard to port (i.e. porting would be less efficient than re-learning)? Did the ST hate Morphic? Someone, please let me know.

bharvey wrote:

What would this look like in the palette?

Maybe this.




saofan123 wrote:

why is it licensed under the agpl instead of the gpl?

No clue.

also, where can i download the source code of byob 3.1.1

As all BYOB was based on Scratch 1.4 (Snap! is HTML5) the source should be in the .IMAGE file.


Also, the dev thread, vol.1 reached up to about 4,500 posts. This is post #3188. We might have User Thread vol. 2 by 2018.

EDIT: To make this post even longer, an idea just popped into my head.
We could start an official Snap! projects forum thread before the social Snap! page is up.

Also, speaking of the social Snap! page, I take back what I said 2 paragraphs up about user thread vol. 2.

Last edited by TruDev (June 18, 2017 12:25:16)


Since beginnings of 1.4, three accounts so far

bharvey
Scratcher
1000+ posts

Snap! user discussion

djdolphin wrote:

What sort of aspects?
Oh, you think I remember? Mainly things about overlapping widgets, and where to drop things, I think, but go search the old BYOB3 thread.

bharvey
Scratcher
1000+ posts

Snap! user discussion

TruDev wrote:

I already knew the “more than one solution” stuff, I was just wondering about this solution. Snap! may have its differences from Scratch, but Snap! will always be cool.
Sorry, I was, I guess, overreacting to “if Morphic is good why didn't the ST use it?”

I know that Jens works better in Morphic, but then why did the ST abandon it? If it's so easily portable, why isn't there a Morphic.swf somewhere in Scratch? Was it too hard to port (i.e. porting would be less efficient than re-learning)? Did the ST hate Morphic? Someone, please let me know.
You're asking this on the wrong thread; we do not want to put words in the ST's mouth. (What I said about Flash vs. Canvas is exceptional in that John Maloney and Brian Silverman and Jens and I had an actual conversation on that topic at a Scratch conference when we were starting work on our respective next systems.)

bharvey wrote:

What would this look like in the palette?

Oh, now I'm confused. Is the equal sign part of the syntax for variadic groupings?

But what I meant was, what does the finished block look like to users, in the palette?

bharvey
Scratcher
1000+ posts

Snap! user discussion

saofan123 wrote:

why is it licensed under the agpl instead of the gpl?
The AGPL is for web services, such as Snap!. The notion of “distribution” in the plain GPL is about letting you download a copy of the executable program to your computer, so it says you have to distribute the source in the same way that you distribute the executable. For a web service there is typically no distribution of executable code, so the language is different.

djdolphin
Scratcher
1000+ posts

Snap! user discussion

bharvey wrote:

djdolphin wrote:

What sort of aspects?
Oh, you think I remember? Mainly things about overlapping widgets, and where to drop things, I think, but go search the old BYOB3 thread.
I didn't start regularly looking at the Snap! threads until 2014ish, I think. I'll try to find it though.
saofan123
Scratcher
47 posts

Snap! user discussion

is byob also under the agpl?
bharvey
Scratcher
1000+ posts

Snap! user discussion

saofan123 wrote:

is byob also under the agpl?
No, BYOB wasn't a web service; it ran on your computer. Plain GPL.

djdolphin
Scratcher
1000+ posts

Snap! user discussion

Hmm, these are all of Jens' arguments against DOM I've found so far:

The closest thing I've found to “overlapping widgets” is this:

Jens wrote:

There are also DOM elements for lots of things, with native implementations and lots of goodies (e.g. text-to-speech). And also with grave downsides. Just ask those who are really using them to build systems and not just shiny web pages. Talk about kludges like inline-SVGs to draw lines, about fiddling with CSS for all kinds of effects, talk about how different browsers interpret these things differently. Try using native text boxes in a block and then make a sprite “say” that block, or take a picture of it, scale that down to a thumbnail, so it can be used as menu item. Try making a native text element display placeholders for blanks. Yeah, you'll succeed, but that's not even starting with building a system, let alone maintaining it and taking it further.
BookOwl
Scratcher
1000+ posts

Snap! user discussion

I wrote a parser combinator library and a demo JSON parser.

who needs signatures
TruDev
Scratcher
80 posts

Snap! user discussion

bharvey wrote:

Sorry, I was, I guess, overreacting to “if Morphic is good why didn't the ST use it?”

It's okay.

You're asking this on the wrong thread; we do not want to put words in the ST's mouth. (What I said about Flash vs. Canvas is exceptional in that John Maloney and Brian Silverman and Jens and I had an actual conversation on that topic at a Scratch conference when we were starting work on our respective next systems.)

Oops, sorry, I should go to the Questions About Scratch thread, right?

Oh, now I'm confused. Is the equal sign part of the syntax for variadic groupings?

Sorry, that's just any text, anywhere.

But what I meant was, what does the finished block look like to users, in the palette?

Something like this:



Needs more explanation?

Since beginnings of 1.4, three accounts so far

bharvey
Scratcher
1000+ posts

Snap! user discussion

TruDev wrote:

I should go to the Questions About Scratch thread, right?
Sounds good to me.

So, presumably when you click the arrowhead, it shows ELSE IF (Boolean) (C-slot) and then left and right arrowheads. But how does the user know that clicking the arrowhead again shows all those things, rather than just another C-slot (which is what comes right before the arrowheads)?

Also, there should be a way to specify something that appears only the first time, like the words “with inputs” in the CALL block.

What makes this hard is trying to come up with a notation that makes simple case simple, and less-simple cases possible.

TruDev
Scratcher
80 posts

Snap! user discussion

bharvey wrote:

So, presumably when you click the arrowhead, it shows ELSE IF (Boolean) (C-slot) and then left and right arrowheads. But how does the user know that clicking the arrowhead again shows all those things, rather than just another C-slot (which is what comes right before the arrowheads)?

Also, there should be a way to specify something that appears only the first time, like the words “with inputs” in the CALL block.

What makes this hard is trying to come up with a notation that makes simple case simple, and less-simple cases possible.

I really am getting confused and lost too, I guess I went in over my head…

How far are you guys with the social site? I'd love to get an update…

Since beginnings of 1.4, three accounts so far

TruDev
Scratcher
80 posts

Snap! user discussion

One more thing. How much money is Berkeley putting into Snap!?

Since beginnings of 1.4, three accounts so far

Powered by DjangoBB

Standard | Mobile