Scratch

ScratchReallyROCKS wrote:

I've got one, it's different than the other ones:

Clever! 

Last edited by Jwosty (2010-08-11 17:35:17)

mooster wrote:

I think panther gave my computer spyware

You should be saying this on the Panther thread!  But it'd help if you give them the details of what you did and why you think so.

fullmoon wrote:

Sooo, how's the conference going? Maybe I'm just out of it, but I can't seem to find anything about it anywhere!

http://events.scratch.mit.edu/conference/2010/media

The conference hasn't really started yet; yesterday there were preconference workshops.  We didn't attend one; instead we spent most of the day talking with Brian Silverman and John Maloney about just how far along the line of

procedures with no inputs or outputs
procedures with inputs
procedures with inputs and outputs
first class procedures

Scratch 2.0 should go.  (Of course you know what we think!)  The first of those would really be little more than a different syntax for BROADCAST AND WAIT.  The second would allow custom commands but not reporters.  The third would allow more or less all of Make a Block but not lambda.

Brian (the other one) points out, correctly, that in the history of Logo, the predecessor of Scratch, very few kids actually wrote reporters in their projects.  We don't know whether kids found it too hard, or whether they just didn't see any need for them.  And we don't really know whether kids are turned off on the whole enterprise if there are a few pieces they find obscure.  We each had some evidence to support our different views.

Oh, we also had an interesting discussion with John about the generic hat block (the one that just has a hexagonal boolean slot as the condition).  John had implemented that a long time ago but they took it out of Scratch partly because of the problem that a user might write a test that's always true, and then the block would keep running forever.  We came up with an idea about that:  A generic hat block should fire if (1) the condition is true when the green flag is clicked, or (2) the condition was false on the previous clock tick but is true now.  Another idea would be to include an on-off switch in each generic hat block so they could be individually disabled.  What do you (all) think about those ideas?

Today the actual conference sessions start.

Oh, P.S., we put a big pile of BYOB buttons on the registration table and they were all gone two hours later.     But don't worry, we have more for today.

What exactly does lambada mean?

shadow_7283 wrote:

  I wish I lived in Cambridge. So, is the Scratch team still unsure about including first-class procedures? They seem pretty adamant about not having all of BYOB3's features.

No, I don't think anyone is adamant about anything (except me -- I want it all!).  But, you know, Scratch has been hugely successful without procedures at all, and people have made tremendously creative projects in it.

We've been batting around a bunch of alternatives.  One idea was to find a way to let people post Scratch-mod projects on the Scratch site, tagged so that you don't see the project unless you have that mod.  That way we'd avoid fragmenting the community (because everyone would still see the core Scratch projects and the Scratch forums etc.) but still maintain Scratch's character as a kid-focused program.
There are pros and cons to that idea.

The hat block would be kind of cool, but I don't really see how it would function any better than a "forever" and an "if" wrapped around the entire script.

That's true, they're equivalent.  But somehow it feels different; I think it's strange to have a script that's always technically running, but only really runs in response to an event.  Also, FOREVER IF runs at the speed of the Scratch clock, whereas hat blocks test their conditions much more frequently, I'm told.

bharvey wrote:

That's true, they're equivalent.  But somehow it feels different; I think it's strange to have a script that's always technically running, but only really runs in response to an event.  Also, FOREVER IF runs at the speed of the Scratch clock, whereas hat blocks test their conditions much more frequently, I'm told.

So basically executing a hat block like this:

When <true> is true:
  stamp

would be faster than doing the same thing in a forever/if construct? That feels strange to me. On the other hand, it much more closely matches Flash's callback-based flow (it's single-threaded  ), and heck, I'll take a speed increase wherever I can get one. You pointed out that having a script that's always running but not really doesn't seem right, and I think that's why this hat block was removed from Scratch in the first place. But basically, that's how everything in Flash works, because you can't just launch a thread with an endless loop in it. So I'm torn.

And thanks for the tip about the experimental viewer! It's epic...but I sure hope we drop the .sb format for 2.0.

Yeah, thank you very much for the link! I always forget to check the announcement forums. XD

EDIT: IT RUNS SO FAST! There isn't any lag when editing scripts!

fullmoon wrote:

So basically executing a hat block ... would be faster than doing the same thing in a forever/if construct?

I may have said it badly.  It's not that the overall speed of the program will be different.  It's that an event will be noticed right away instead of at the next clock tick.  This would matter only if an event is over very quickly, e.g., a mouse click that lasts less than 1/20 sec.

Oh, and I believe that the current implementation of broadcasts is tightly integrated with hat blocks, which is why there's no <I RECEIVED foo> block.

Lucario621 wrote:

I was just comparing your logic to those of the scratch team and how you complain about them 

I did see the " " but just for the record, I try really hard not to complain about the S.T.; I disagree with them about some things, which is different.  We're all friends.

And, the disagreement isn't about whether all possible ideas should be included!

I have no idea what pointers even are!    (and don't bother explaining lol)

I'll let nXIII do that. 

bharvey wrote:

fullmoon wrote:

When you say the next "clock tick", do you mean the next time Scratch executes the loop, or the next time Flash actually gets a timer tick?

Scratch.  The Scratch evaluator is actually deliberately slowed down so that projects run at about the same speed on all computers, fast or slow.  1/20 sec is a really long time by computer standards, although fast enough not to be annoying to human beings.

How would you change that?

ScratchReallyROCKS wrote:

How would you change that?

Well, in BYOB we've replaced the artificial slowdown with real useful slowdown. 

BYOB takes up every letter for arguments, so how can I add dropdown menus in blocks? uncoloredArgMorphFor is full.

shadow_7283 wrote:

Baa Baa zoo pals,
Quack Quack zoo pals,
Oink Oink zoo pals,
Zoo pals make eating fun! XD

Lololololololololololololololololol *insert more lols here*