Scratch

shadow_7283 wrote:

Scratch seems to be slipping away from the emphasis on programming it once had.

As of right now, the Scratch home page says "643,922 registered members, 182,259 project creators."  About a quarter of the users are programmers.  I don't think that's anything new; it's always been a minority of Scratchers who actually create projects.  And a lot of Scratch projects have always been light on programming; they're "add your name to this" or they're slideshows with one FOREVER [NEXT COSTUME] script.

This shouldn't surprise you.  Programming is hard -- not impossibly hard, not out of reach, but way harder than letting someone else do the programming and just playing the games other people upload.  In my Scratch class for 4th and 5th graders, when I leave them to their own devices, some spend a lot of time in the sprite painting window, or recording themselves making silly noises, or taking pictures of each other; very few really buckle down to writing interesting scripts if I don't insist.

And, even though I'd rather every kid be a terrific programmer, I think this is actually okay.  They're all being creative in their own ways.  (Some of the people painting stuff are more creative than the boys whose programs are always about blood-spattered cats and exploding people.  It's always boys.    )

On the other hand, it's more than okay, it's terrific, that some kids really get it about how empowering programming can be, and push themselves to learn how to do everything.  We absolutely should give kids like you the best tools we can.

BYOB development isn't going to stop!  The pace will be a little slower than last year. (You guys saw about half of the string of daily releases that went into getting the 3.0 design exactly right; before the public alpha release there were many versions used by only a handful of people.)  Three things are different now: (1) Last year we lived and breathed BYOB full time; this year Jens and I have each had to pay some attention to the rest of our lives.  (2) There's a pretty decent BYOB for people to use, so the pressure is lessened.  (3) We are now working in two directions at once: the completely rewritten BYOB 4.0 that'll run at a reasonable speed, and the interim BYOB 3.1 that'll still be slow, but will add things like first class sprites.  Only the 3.1 effort will be immediately visible, but the 4.0 effort will pay off more in the long run, I think.

shadow_7283 wrote:

I keep telling myself to learn a programming language like C#

If you're seriously interested in programming, of course you have to expand beyond Scratch.  (That doesn't mean you have to abandon Scratch; you can do both.)  I wouldn't pick a Microsoft-spawned language like C#, though; if you want to learn that kind of language it might as well be Java, so you can talk to the rest of the world.  But of course what I really want you to learn is Scheme!  (Mainly so you can read SICP, which really is by far the best CS book ever written.)

It was really tactless and selfish of me to post:

That's why I'm turning to BYOB3. Jens and bharvey, don't let me down!

Sorry. 

Not at all!  Having users who care is what keeps us going.  And I heard the compliment that was inside what you said.    But, you know, the step from first class procedures and lists to first class procedures, lists, and sprites isn't going to be half as exciting as the jump from not thinking about first classness to having first class procedures and lists.  BYOB (I hope this doesn't sound smug) is probably right now about 80% as good as it'll ever be.  The rest is details.  Important, but not earth-shaking.

Meanwhile I haven't had a spare hour in three months to spend on getting the tutorials to match the actual 3.0 behavior -- mainly getting rid of the variables area at the left of the block editor.  But next semester I won't be teaching three classes, so I should make some progress starting in January.

shadow_7283 wrote:

I have to say, Scratch Suggestions has really frustrated me...
It seems like people want Scratch to evolve in to a YouTube-type website.

If I had time, I'd like to go through all the (600-odd, I think) suggestions and categorize them as being about the web site, about the forums, or about Scratch itself, and then in the latter category further subdivide them into ones that would be doable by the user in BYOB and ones that wouldn't.     It'd be interesting to see what the ratio is.

I don't like Java much; Java exploits are half the viruses I get on this computer. 
But Scheme sounds interesting. Maybe I'll try it. I was thinking C# though, because it would help me out with Unity 3D, and it is somewhat of a standard for software development.

bharvey wrote:

Is this the same kid talking who won't settle for anything but MIT?    If you do go there, you're going to work your butt off!  And wherever you go to college, you're going to learn a few more programming languages.  It's not a good idea to tell yourself stuff like this about yourself; it can be self-fulfilling.

I'm not sure exactly what you mean. But you can bet that I'll be working as hard as I can for MIT (come to think of it, I already am). 

Last edited by shadow_7283 (2010-10-31 11:38:09)

xly wrote:

Is "Racket" same as Scheme or not?

A particular well-known group of Scheme implementors have decided that Scheme isn't quite the language they want to work in, and so they've invented a new language, Racket, that has a large intersection with Scheme but is different in certain ways.  It remains close enough to Scheme so that their implementation allows Scheme compatibility as a mode you can select.

If you're reading SICP I think your best bet is to get our package from http://inst.eecs.berkeley.edu/~scheme and run the stk-simply version from inside Emacs.

nXIII wrote:

My idea for 3.1: move zero-argument reporters to the "variables" pane.
Basically, all those zero-argument reporters (size, x position, direction, etc.) would be moved to the variables pane and be treated as variables. This means one would be able to set them with the SET () TO () primitive, and all the other SET primitives would become obsolete. One could also override the default behavior of these variables, such as transforming (e.g. scaling or rotating) the x/y position variables from their values.

Oh. I just realized that wouldn't work.... If you can override the behavior of the SET (x position) TO () block, how would you set the x position in your function? I mean, for x/y position it's obvious, but what about size? Hm. Any suggestions?

Why would you want to override the blocks' default behaviors? That doesn't really make any sense. If you were to set  the "X Position" reporter to function as the size reporter, it wouldn't do anything that the size block couldn't. It would just create confusion as to which variable does what.

The other problem with your idea of having "zero-argument reporters" in the variable pane is that they would be treated like other variables. That might work in Scratch, but with first-class everything in BYOB that would create a major issue. How would a sprite go to the x position (set x to [say "Hi!"])?

Lastly, I don't want more clutter in the variable pane. I usually have TONS of variables there, and I'm perfectly happy with the zero-argument's current location.

nXIII wrote:

If you can override the behavior of the SET (x position) TO () block, how would you set the x position in your function?

Much as I love the elegant spirit of this proposal, I see a bunch of difficulties with actually doing it.  For one thing, with the pen down, GO TO X:Y: doesn't decompose into SET X and SET Y.  So if you really want to maintain that these sprite properties are modelable as just variables with side effects, then the right thing is to make POSITION (a list of length 2) be the variable, and still consider X POSITION to be a niladic function reporting ITEM 1 OF <POSITION>.

But also, even if you think of them as variables (as do the Scratch Team -- I asked John about this once), they still don't go in the Variables tab.  Otherwise pretty soon you'll find that Variables is the only tab, which sort of defeats the object of tabs.  Your model has to allow for variables of all colors, just as we let you write custom blocks of all colors.

Some niladic functions can't reasonably be viewed as variables; the paradigmatic example is a RANDOM DIGIT block that chooses a random value from [0,9].

But the particular problem you're stumped by seems easy enough to me.  You just subclass sprites to create transformable-sprites, then you use SUPER (a variant of RUN/CALL) to get at the underlying mutator.  Of course this assumes that we work sprites into a serious object oriented framework.

As a matter of learnability, though, I don't think we should turn BYOB into a dialect of Smalltalk.  It should remain a dialect of Scratch, which is to say a dialect of Logo, which is to say a dialect of Lisp.  Operator first; ASK <obj> <message> (or RUN [<method> OF <obj>] -- we really should work out how sprites-as-objects can coexist gracefully with dispatch-procedure-as-object) rather than just <obj> <message> to talk to another object.  Etc.  So don't be fooled about syntax by my use of SUPER above.  In Object Logo we used names like USUAL.FOO to mean "run FOO in this object, but using my parent's method."

shadow_7283 wrote:

Why would you want to override the blocks' default behaviors? That doesn't really make any sense. If you were to set  the "X Position" reporter to function as the size reporter, it wouldn't do anything that the size block couldn't. It would just create confusion as to which variable does what.

As in any object inheritance system, a sensible programmer will override methods in subclasses not with arbitrary different methods, but with specializations of the parent methods -- things that have the same basic purpose, but do it differently.  The classic example in Logo circles is to create a turtle (sprite) subclass whose pen draws dashed lines instead of solid lines.  nXIII's example is a subclass of sprite that moves in a coordinate system other than the conventional one in which the axes are perpendicular and have equal-sized steps.

It may not be obvious why you'd want this, so I'll give two simple examples.  (1) In the early days of PCs, moving one pixel up or down the screen was a different distance from one pixel sideways.  So trying to draw a square with a REPEAT 4 [...] would instead get a rectangle wider than tall or vice versa.  We'd fix this by changing the scale of the Y axis.  (2) It's pretty easy to draw (a close approximation to) a circle with a REPEAT 360 [...].  But it's quite a difficult challenge to draw a non-circular ellipse with turtle motions.  It becomes easy if you can scale the axes.  And if you make them non-perpendicular you can tilt the ellipse.

The other problem with your idea of having "zero-argument reporters" in the variable pane is that they would be treated like other variables. That might work in Scratch, but with first-class everything in BYOB that would create a major issue. How would a sprite go to the x position (set x to [say "Hi!"])?

Even in Scratch it wouldn't make much sense to put a text string into the x position.  You'd have to have the idea of "active variables."  Any variable could have a "setter function" associated with it, and [SET <var> TO <val>] would really do [SET <var> TO [CALL [SETTER FUNCTION OF <var>] WITH <val>]].  The function could report the same value it was given (maybe after doing other things with it), report a different value (solving nXIII's coordinate transformation problem), or throw an error (solving your value-not-in-domain problem).

Lastly, I don't want more clutter in the variable pane. I usually have TONS of variables there, and I'm perfectly happy with the zero-argument's current location.

Here we agree.

shadow_7283 wrote:

I'm too busy with school.

Yeah I'm with you there! 

bharvey wrote:

ScratchReallyROCKS wrote:

I was thinking, what about taking away the "Make a variable" and "Make a list" buttons? It would definitely save space in the variables pallet.

"Make a list" is definitely redundant, since you can put lists into variables, but I'm not quite sure how you'd do without something like "Make a variable."  I suppose it could be a block instead of a special user interface feature.

We kept "Make a list" because we didn't want to have any unnecessary incompatibilities with Scratch.  I believe a Scratch user can run BYOB, ignore the new stuff, and work exactly as before.  We thought that mattered more than saving a little space.

But what did you mean about "Make a variable"?

[script variables (a) (b) >]

MathWizz wrote:

ScratchReallyROCKS wrote:

[script variables (a) (b) >]

Global variables?

Exactly.  The SCRIPT VARIABLES block makes variables local to the script in which it appears, even if that script is in the sprite's scripting area rather than in the Block Editor.

P.S. You guys should learn to edit down long quoted previous posts! 

I'm kind of running out of ideas for practical projects that really take advantage of BYOB3's features. Any ideas?

It'd be nice if it is entertaining... 

Last edited by shadow_7283 (2010-10-31 17:19:51)

shadow_7283 wrote:

But if I were to use <[list 1] contains []> it wouldn't find an item of that secondary list. This seems like a major drawback to me.

It seems like first-class data in BYOB3 isn't completely first class yet. Am I right in saying that?

No, I don't think so.  First, even if you were right about how CONTAINS should behave, that's got nothing to do with first-classness.  If CONTAINS wouldn't take a list of lists as input, that would be closer -- although you don't complain that [<> + <>] doesn't take lists as inputs.  Some functions have natural domains that don't include every data type.

But, second, I think you're wrong about what CONTAINS should do.  On your view, the list of lists

[[1 2 3] [a b c]]

would basically mean the same thing as the flat list

[1 2 3 a b c]

This would decrease, not increase, the usefulness of being able to construct lists of lists.

P.S.  But thanks for bringing up this example!  When I first wrote DEEP-CONTAINS I did it this slightly simpler way:



which should have worked, but didn't, for the bizarre reason that when I closed the Block Editor, the grey-bordered function changed to [<item> DEEP-CONTAINS <>]!