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.

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.

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?

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?

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

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

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.

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.

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?

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.

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.

is byob also under the agpl?

saofan123 wrote:

is byob also under the agpl?

No, BYOB wasn't a web service; it ran on your computer. Plain GPL.

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

• Morphic allows a more intuitive GUI and control over every pixel
  
• Morphic will be fast anyway
  
• Scratch doesn't use native widgets
  
• DOM doesn't look the same everywhere and is kludgy
  
• Jens wants Morphic because he likes Morphic
  

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.

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

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?

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.

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…

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

TruDev wrote:

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

That's okay. If a design issue isn't immediately obvious to Jens, you have to expect that we mortals are going to find it challenging!

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

The social site depends on some enhancements to the Snap! cloud server. That code is written, and slightly tested, but not yet with real data. We are waiting for school to be over (June 30 in New York) so we don't have any year-end disasters. With luck that will happen the first week of July. At that point, we can take the also-written-and-slightly-tested front end and put it up for users. Of course what will probably happen is a huge disaster that first week and then more debugging. So I think that mid-July is the earliest you can expect to see it, and late August the latest. (We are all totally hoping to be able to show it off at the Scratch conference in Bordeaux July 18-21.)

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

Berkeley isn't putting any money into it – universities are poor, especially these days. In our first National Science Foundation grant for the BJC curriculum, we budgeted $100K in 2012 for the initial Snap! development. (That was a huge chunk out of a $500K total budget, especially given that the NSF solicitation was about teacher professional development, which is where the rest of the money went. We had to work at talking them into it.)

But really, since BYOB3 in 2008, almost all of the development has been Jens volunteering his time.

We are hoping that Jens's current employer will support Snap! development. Nothing is at all settled so far, but people there have made encouraging noises. Cross your fingers.

BookOwl wrote:

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

Not ignoring you – I started looking at this project but it'll take a while for me to figure it out.