Scratch

Hey, does anyone live in or near Tokyo?  I'm taking this tour of Japan in May, and it strangely spends just one night in Tokyo on the way to the flight home, but I'd like to stay a few days at least; there seem to be at least a dozen art museums.  But I'm nervous about the impression I have that Japan is the last place left on earth where non-native-language-speakers have a really hard time.

Anyone here with experience using Snap! 4.0 in the classroom? I'm thinking about switching from 3.1.1 to 4.0 and would very much appreciate your thoughts about this change. Have you done it? How did it go? What problems did you find? How did you solve them?

MMSequeira wrote:

Is the

(clone)

block available in Snap! 4.0? I couldn't find it.

It'll be in 4.1, but for now we're putting our priority on things like the cloud back end.

I've just tried to implement quicksort using Snap! 4.0. It is a bit slow... :-) Perhaps a sort block for lists would be appropriate? What about support for maps/hashes?

MMSequeira wrote:

I've just tried to implement quicksort using Snap! 4.0. It is a bit slow... :-) Perhaps a sort block for lists would be appropriate? What about support for maps/hashes?

We are trying not to include as primitive anything that learners could write for themselves.  The goal is that they be able to see both above and below abstraction barriers.

Without seeing your code, I'm guessing that you combine functional and imperative list blocks on the same list.  That'd slow things down.  Either stick to the Scratch-style list blocks or stick to the Lisp-style ones.

But if I really wanted to sort a list quickly in Snap!, I'd use mergesort.

bharvey wrote:

What you really want is a Chinese translation of a programming language with primitives like "Where is the lavatory?"

Cèsuǒ zài nǎr ma? 
This is possibly the only phrase in Mandarin that I've retained from Rosetta Stone...

bharvey wrote:

roijac wrote:

Did you put a wrap around it?

Roijac means "warp."   

I did not! Way to go! It is *much* faster! Thanks a lot! But what exactly does it do?

MMSequeira wrote:

But what exactly does it do?

It's like "atomic" in BYOB.  Whatever's inside the warp block runs without interruption until it's done (so, in particular, nothing will be displayed on the stage until it's done).

bharvey wrote:

MMSequeira wrote:

But what exactly does it do?

It's like "atomic" in BYOB.  Whatever's inside the warp block runs without interruption until it's done (so, in particular, nothing will be displayed on the stage until it's done).

Really? My code (still) includes a few say blocks for tracing purposes. They all seem to go through. What am I missing?

By the way, Snap! 4.0 is single threaded? Where can I find a technical description of these issues?

MMSequeira wrote:

So, when you "save" a project in Snap! 4.0 the URL is changed so that it includes the whole project, right?

That's correct. You can also choose "Export project…" from the File menu to export your project as a standalone XML file (you can save this more easily to your local drive if you need it there).

MMSequeira wrote:

What are continuations, by the way?

The continuation of a block in a script is the stuff that still has to be done after the block finishes.  In the case of a command block, this means the blocks below it in the script.  For a reporter block, the continuation includes plugging the reported value into the caller of the reporter as well as the stuff below it.

Like other Scheme dialects, Snap! allows a continuation to be used as data, in the form of a procedure that can be called, from an entirely different point in the computation, to carry out the continuation.  The continuation of a command is a procedure with no inputs; the continuation of a reporter is a procedure with one input, namely, the value that the continuation should use as the returned value from that reporter.

CALL W/CONTINUATION and RUN W/CONTINUATION take as input a procedure with one input.  That procedure isn't a continuation!  But it will be called with a continuation as its input.  Typically the procedure stores the continuation, maybe in a global variable, to be used by some other part of the program.  Look at the implementation of CATCH and THROW to see an example of using continuations.

Of course, it would be great to have some way to share tools/libraries.

Coming.  The initial release of our server will have only private storage of projects, but sharing will be added reasonably quickly.

The problem I see with that right now is that I use Snap! 4.0 localized to Portuguese...  However... custom blocks are not localizable.

Yup, good point.  Of course, in practice, you're not going to provide localization of your blocks into every other language!  So this will, I'm guessing, give English even more hegemony than it has already.     But, yeah, we should provide a way to do that.  Maybe in version 4.2 or something.

even WARP-ed scripts yield once every 500 ms to update the display (e.g. in case they cause an error) and to allow user interaction, particularly with the red stop sign button. Also, interpolated ("timed") blocks like SAY, WAIT, PLAY NOTE, REST and all blocks named ... AND WAIT or ... UNTIL DONE break out of atomicity and will constantly yield even if inside a WARP block.

As Manuel correctly assumes, Snap! runs in a single OS thread. However, Snap's Morphic kernel is at its heart a timesharing multiplexer which schedules "green threads", thus basically providing its own little operating system. As Brian points out, this lets us implement threads nicely in Snap, but - maybe even more importantly - it enables a very direct, interactive and "lively" IDE. For example, it lets you click on running scripts to stop them, or it lets you drag things around, click buttons, change blocks and scripts and edit inputs while scripts are running, and even modify those scripts which are being executed "live".

Last edited by Jens (2012-11-15 07:26:26)

Thanks for explaining continuations! I'll study the blocks that use them.

bharvey wrote:

MMSequeira wrote:

The problem I see with that right now is that I use Snap! 4.0 localized to Portuguese...  However... custom blocks are not localizable.

Yup, good point.  Of course, in practice, you're not going to provide localization of your blocks into every other language!  So this will, I'm guessing, give English even more hegemony than it has already.     But, yeah, we should provide a way to do that.  Maybe in version 4.2 or something.

I could share my tools in Portuguese and English. Other people might take them, add their own localization, and update the shared tools, so that now they would be available in another language. If sharing and managing versions of tools is available, interesting libraries would develop faster, with contributions from all over the world. Scratch/BYOB/Snap! are already strong in their support for other languages. It's just a small step from here. :-)