Scratch

LOL, now that I'm learning JS, I see that a-lot of the tools blocks you included are JS code!

sci_test wrote:

LOL, now that I'm learning JS, I see that a-lot of the tools blocks you included are JS code!

A lot of the tool blocks are just obvious; for example, every language I know of except Scratch has a FOR mechanism of some sort.  As for the higher order functions, both BYOB and JS learned these from Lisp.  There was no direct influence from JS (which I haven't gotten around to learning yet    ) on BYOB Tools.

One could argue that most of the fundamental ideas of computer science were in place by 1945 or so, when there were only a handful of computers in the world, thanks mainly to Alan Turing and Alonzo Church.  Yet here we are, 60 years later, still having arguments about the utility/learnability of lambda.

scimonster wrote:

Like, I recognized ...

I think the big idea here is that you can write those tools in BYOB.  JS includes some of those in the language because it's not so easy to write them yourself in JS.  (Does JS have all four WHILE-type blocks?

WHILE < > DO [ ]
UNTIL < > DO [ ]    (basically the Scratch REPEAT UNTIL)
DO [ ] WHILE < >
DO [ ] UNTIL < >

Most languages have only one (like Scratch) or two of these, even though all four are different and useful.  We don't include any of them, because we provide the ability to write them yourself.)

bharvey wrote:

This is why I've been working hard at convincing Mitchel and the Scratch Team that these features belong in main line Scratch!  We view BYOB 3 as a "proof of concept" that kids won't be frightened away even if they don't immediately "get" first class procedures.  (And I think a kid who isn't ready to write MAP can still learn to use it if a teacher provides it.)

Scratch could have levels of programming.  You could choose beginner, intermediate, or advanced programming, and different blocks or features will only be shown in their category.  Anyone like this idea?

LiquidMetal wrote:

Scratch could have levels of programming.  You could choose beginner, intermediate, or advanced programming, and different blocks or features will only be shown in their category.  Anyone like this idea?

We've discussed this with the Scratch Team.  They worry that some kid who's at beginner level will find a project on the site that uses blocks s/he doesn't know about.  You could restrict beginners to see only beginner-level projects, but I think seeing other kids' masterpieces helps motivate kids to move past being beginners.

Last edited by bharvey (2011-07-18 15:49:59)

shadow_7283 wrote:

I believe I mentioned this idea quite a few pages back. The idea is that there isn't ANY separation in the Scratch community, even between novices and experts.

Agreed.  That's what I really want: for them to embrace wholeheartedly the BYOB ideas about first class data.  I don't believe that people will find that world any more confusing than beginners already find unreadably dense Scratch-expert code scripts.  Anything else we work out will be a compromise.

Still, it does have some merit. It might prevent the temporary scares that a few people get when the first open up BYOB. 

I believe that what we need is tutorials that start way before the current BYOB3 tutorials.  I wrote those with BYOB2 users as the intended audience, so jumped right into the things that were new in 3.  But this school year, when I have a lot of time, I want to make tutorials starting with one just about Scratch-level features, then another about simple non-recursive Make a Block examples, and /then/ the ones you've already seen, and then two OOP ones (3.1 sprite-based OOP and lambda-based OOP).  And maybe more.  But of course I can't work on those until I know what the Snap user interface will look like!

Is there support in BYOB for creating networked applications (e.g., simple 2-player or multiplayer games)? If not, is anyone aware of a Scratch variant that does provide such support?

scimonster wrote:

Are you talking about Mesh?

Meshes are a disappointing because they only work over a LAN unless you use tricks.

It was worldwide in NetScratch (or whatever it was called) which was discontinued.

LiquidMetal wrote:

I'm sorry to say this, but even after watching the 20 minute video thing and some tutorials, and reading the pdf, I'm still completely lost as to how some things work, and why you need some others.

Don't be sorry; this is good feedback for us!  Please ask lots of questions as needed.

For example, how do you anchor one sprite to another?

There are two ways, the GUI way and (as of 3.1) the programming way.

The GUI way is a little tricky.  You pick up the image of the sprite you want to attach as part of another sprite from the sprite corral in the lower right corner of the screen, and drag it to the "anchor" sprite on the stage.

The programming way uses the ATTRIBUTE block in the Sensing palette:



The reason THE BLOCK is needed is that the value of the ATTRIBUTE block alone would be a sprite, whichever sprite is currently the anchor of this sprite (or NIL if this sprite has no anchor).  But what SET needs isn't that value; it needs to know what attribute you want to set.  When you say

[THE [ATTRIBUTE (ANCHOR)] BLOCK]

the value of that is the ATTRIBUTE block itself, and SET can examine that to see which attribute to set.

Is that clear?  If not, please try to let me know where I lost you.

LiquidMetal wrote:

What does it mean that everything is first class?

Well, first of all, it's a slogan; we haven't achieved it yet.  (Still to come: first class costumes, first class sounds, and lots more.)

A data type (not a specific value of that type -- the type as a whole) is first class if values of that type can be used as flexibly as numbers, basically.  The formal definition is that values of the type should be able to be

1. The value of a variable.
2. A member of an aggregate (BYOB: a list item).
3. An input to a procedure (BYOB: block).
4. The value reported by a procedure.
5. Created without a name.

The paradigmatic example is the type List.  In Scratch, lists have none of those properties.  You can't [SET <var> TO <list>]; you can't use a list as an item in a bigger list; blocks don't take lists as input or report lists; and the only way to make a list is the Make a List button, which right away asks you for a name for the list.

But BYOB lists /can/ do all five of those things.  So, we say that lists are first class in BYOB.

The more data types are first class, the more you can manipulate them using the normal mechanisms of the language instead of needing special case mechanisms for each type.

In particular, making procedures first class just explodes the expressiveness of a language.  That was the big new idea in BYOB 3.0.  (Well, new to Scratch circles; it's about 75 years old in computer science circles.)

What does the run block do? Can't you just put whatever you put inside that where you put the run block and it will work the same way?

Yes.  It would be unusual to use the RUN block with a specific, constant script in its input slot.  Instead, the power of RUN is that you can give it a variable (or other computed expression) whose value is the script to run.  This lets you write a block that takes a script as input and runs that script conditionally, or repeatedly, etc.  So if you look at our implementation of FOR, you'll find the block

RUN (ACTION)

where ACTION is a variable, one of the inputs to FOR.  That RUN block is inside a REPEAT UNTIL, so the same script will be run repeatedly.

In 3.1 there actually is a reason for using RUN with a fixed input: the input would be a [( ) OF ( )] block to select a method of a different sprite.  This is like asking the other sprite to do whatever is in the script.

Why do you consider (clone) an operator?

We discussed this quite a bit.  The advantage of our way is that you can use the reported value (which is the clone) for various purposes, of which the easiest to understand is probably this:

REPEAT (10)
   ADD (CLONE) TO (list-of-clones)

to keep track of this bunch of clones in a list.  The other common one is the situation in which each clone needs to run an initialization method when created:

LAUNCH [[INITIALIZE] OF (CLONE)]

creates a clone and initializes it all in one instruction.

Why don't lists go all the way to the right like they do in scratch?

Sorry, I don't understand this question.

What are potential uses of the ([list] as text) block?

In Scratch, as a partial fix for the non-first-classness of lists, the red oval block with the list name is a reporter that reports a text string containing all the items of the list separated by spaces.  This is a kludge; clearly, once you have first class lists, the red oval list name block should report the list. not some reduction of the list to a flat text string.

But we wanted to be able to load old Scratch projects that depend on the old kludgy Scratch behavior.  When BYOB loads a Scratch project that has a list-name-oval block in a script, it changes that list name block to <list> AS TEXT, which does the old Scratch thing.

It's there only for compatibility.  We discourage the use of AS TEXT in new programs.

Why don't you put the left and right arrows on the (join [] []) block?

At the time, we were still hoping that the Scratch Team would just buy our whole package of ideas and incorporate them into Scratch 2.0.  So we really bent over backward not to make unnecessary changes to existing Scratch features.  But, you're right, there's no reason JOIN shouldn't take multiple inputs, and we'll get around to that at some point.

Also I think the concept of with inputs is a little hard to understand.

Hmm.  Have you had an algebra class?  Are you familiar with problems like:

g(x)=2x+7.  How much is g(5)?

If you'd defined a reporter G, you could answer that question by saying

CALL (G) WITH INPUTS (5)

(it's "inputs" rather than "input" because there might be more than one of them, even though in this case there's only one.)

Is that enough explanation?

And are there any large scale projects made currently with byob that I could use to see what it can do?

Up to now, the really large-scale projects run too slowly to be bearable; that's what we're going to fix in 4.0.  But there are some interesting examples in the Examples folder that you get when you click File>Open.

I noticed if you put an extra input, it will do nothing.

If you make variables work the way panther has them, it would increase first classiness.

Even more so; what if all blocks were potentially everything?  For example, the clone block, it is a stack block, but if you put it in a place where a (blocklikethis) goes, it can switch for that instance of the block.  Some blocks might not work like this, those you just couldn't put in those spaces, but it would be good for some blocks.

And when do you think 4.0 will come out?

Last edited by LiquidMetal (2011-07-20 21:56:28)