Scratch

bharvey wrote:

titaniumbones wrote:

Wouldn't be great if "shoot" spawned a new "bullet" sprite, by passing a signal to 'bullet' that included x,y, and direction information?  Is this already possible?

Yup!  (Well, as soon as we can spawn sprites from a script at all.)

In the bullet sprite, define a for-this-sprite-only custom block NEW BULLET with inputs XPOS, YPOS, and DIRECTION.  This is where you put the CLONE ME block.  Then, in the gun sprite, you say

LAUNCH [<NEW BULLET> OF <BULLET>] WITH INPUTS <xpos> <ypos> <dir>

That's the OF block in the sensing menu.  First choose the sprite, then the local variables and blocks will appear in the dropdown on the left.

ah. great.  I completely missed 'launch'.  Thanks so much.

bharvey wrote:

titaniumbones wrote:

I'm trying to figure out how to use BYOB in a computer club filled with 10-year-olds...
Has anyone else done anything like this before?

In my own group of 10-year-olds, a bunch really liked the idea of learning a cool new version that nobody else had yet (this was a year ago), but quickly cooled off when I told them they couldn't upload BYOB projects to the Scratch web site. 

But I'd be super interested to see anything in the way of curriculum that you invent!

well, we'll see.  I'm not particularly impressed with my pedagogical methods just yet. This year, though, I have 3 kids who've worked with me before, and a bunch of younger, much less advanced kids -- so I think the couple of the older kids might be up for trying something new.  The lack of a website is a huge drawback for them, though, I will certainly admit that.

Jens wrote:

Thanks, Matt! We're currently conducting some very preliminary "thought experiments" trying to whip up something to play with along the way. There will be some experimental blocks and other changes to the GUI soon, but it's all in flux and bound to change often, so it's probably best not to use these pre-alpha versions for any long-term projects yet. Other than that I'm thrilled to share development builds and listen to your thoughts on the issues we're discussing    (e.g. prototype based inheritance for sprites)

Well at the speed you guys are working I ought to be able to restrain my impatience -- things are moving so quickly! 
Overall, I am more or less seduced by Lieberman's paper, though I'm not entirely convinced by the cognitive arguments he makes about prototypes. 

Here's one question:  we've talked a lot about what happens when a user changes something in a clone.  What should happen when a user changes something in the prototype?  As a rotten programmer, I tend to work this way: 
- hack up a first draft.
- rashly make some copies
- realize an error, or a feature I would like to include
in class-based OOP, I would then go back and simply modify the parent class.  All my subclasses & instances would benefit from those changes.  In the current implementation, though, modifications made to a prototype don't seem to affect the clones.  Maybe it shouldn't; but the kids who are *one* audience for BYOB are like me insofar as they are constantly and forgetfully updating their code.  One fantastic feature of BYOB is the ability to put crucial bits of code into functions that can then be modified one time for all sprites.  It seems to me of practical utility to have the same kind of framework for sprite families -- though it may contravene some of the Lieberman-inspired design principles. 

So far so great.  I'm really looking forward to 3.1 & all the intermediate steps.  Thanks as always for a great tool,
matt

titaniumbones wrote:

What should happen when a user changes something in the prototype?

The exact details are still under discussion, but the broad principles are

1.  It will be possible for prototype and children to share a common value, so that changes in the prototype will be seen by the children.  Custom blocks will almost certainly behave this way by default.

2.  It will be possible for prototype and children to have separate values for the same named thing.  System attributes such as position and heading will very likely behave this way by default.

3.  To some extent it will be possible for the user to control which of those two conditions applies to any particular attribute of a sprite.  We are still feeling out the details on this point.  For example as of this moment we are in disagreement about whether a child should be able to change the value of a variable seen by its prototype (and therefore its siblings).

But don't worry -- based on the 3.0 experience, Jens and I will be having arguments the day before the release, and it'll nevertheless turn out to be something we're both proud of. 

bharvey wrote:

scimonster wrote:

I have 3.0.8 but i'd like to compare with older versions.

How much older?  3.0.7?  2.99?  2.0?

maybe the original!

I think class based OOP is less confusing because it allows the class to not have to be an object that exist at any given moment and gives a feeling of officialness and organization. I guess I'm just saying that it makes an object seem less like 'just a copy'. Also it seems confusing for variable inheritance to come from the instance parent instead of a list of default values for a class because one of the connotations of something being an object is that it is solid, self sufficient and not connected to something else, otherwise those two connected objects would be one object.

P.S. I have no idea if I'm getting my point across because I'm a horrible communicator.

14God wrote:

I think class based OOP is less confusing because it allows the class to not have to be an object that exist at any given moment and gives a feeling of officialness and organization.

I think the point about "officialness" does capture the main difference between class/instance OOP and prototyping OOP.  Class/instance works great if, before you do any actual programming at all, you carefully plan out an object hierarchy with all the necessary pieces.  Prototyping is much better for "bricolage" (Papert) or tinkering -- the sort of thing people actually do in Scratch!  It's definitely a very different style of work.  Since I'm a tinkerer myself (my colleague Mike Clancy characterizes my programming style as "debugging a blank piece of paper"    ) I'm a big fan of prototyping.

If you really want classes, all you have to do is make a sprite and hide it!  It'll act as your class.

Also it seems confusing for variable inheritance to come from the instance parent instead of a list of default values for a class because one of the connotations of something being an object is that it is solid, self sufficient and not connected to something else, otherwise those two connected objects would be one object.

Oh, I disagree with this!  Class/instance OOP has inheritance, too; it's vital for code reuse.  And the classes can provide class variables, which allow siblings to interact -- to be "connected" without being one object.  The details are different but you can't build an object system without inheritance in some form.

I think that people who've learned Java or C++ or some such language have just developed particular ways to think about OOP, but they aren't laws of nature.  I'm betting that OOP-naive Scratch users will understand prototyping more easily than class/instance OOP, because with prototyping nothing is invisible, the way classes are.  One of the Scratch design goals was to keep everything visible on the stage.

We're still in pre-alpha, bear in mind, so I think the final product will look much smoother to you than what we're playing with right now.  Have faith for a while. 

"should NOT make us forget"

What if you want to spawn a bullet from a gun not a bullet? And if variables are inherited from the spawning instance instead of the class defaults, what if a 'goat' instance spawns another goat... and its age variable is 10, shouldn't the child goats age be 0? and shouldn't that be implied not user implemented? (I'm sorry, think there are valid arguments on both sides, class and prototype. It's just because I'm new to the concept and am somewhat 'shy'    )

bharvey wrote:

Have faith for a while. 

ok 

btw- will prototyping still allow me to say something like "object.isa('class name')" ?

Another day, another experimental version!

Jens wrote:

This experimental version introduces first class sprites in addition to prototype based inheritance of sprite-only variables, lists and custom blocks. There is a new reporter block in the Control category with a drop-down menu which answers the object (sprite or stage) indicated by the name in the drop-down. You can store and retrieve objects in variables and lists (try stage watchers on such variables and lists, and double-clicking on sprite-reporters!), pass them to blocks which (now) accept sprite arguments (try SAYing a sprite) and create new sprites by spawning existing ones. There are also some experimental blocks to play with, and the basics of the file format are also in place.

The tricky part is getting a clone to do something programmatically, this part (the OF block) is still very much under construction. And this isn't anywhere near functional. There are lots loose ends (so please don't report any bugs in Bugzilla about this version    ), because these features required major internal changes, which will yet take a while to complete.

Otherwise, enjoy!
--Jens

bbbeb wrote:

I don't have much free time anymore. I hate school.

Yeah, me too!  Both halves.

bharvey wrote:

titaniumbones wrote:

What should happen when a user changes something in the prototype?

The exact details are still under discussion, but the broad principles are

1.  It will be possible for prototype and children to share a common value, so that changes in the prototype will be seen by the children.  Custom blocks will almost certainly behave this way by default.

2.  It will be possible for prototype and children to have separate values for the same named thing.  System attributes such as position and heading will very likely behave this way by default.

3.  To some extent it will be possible for the user to control which of those two conditions applies to any particular attribute of a sprite.  We are still feeling out the details on this point.  For example as of this moment we are in disagreement about whether a child should be able to change the value of a variable seen by its prototype (and therefore its siblings).

when you talk about attribute values, do you mean just variables or also scripts?  It was scripts in particular that was worrying me here -- because I;ll write a script which seems to work, clone a sprite once or twice, then realize the script is a little bit broken.  It's nice in that case not to have to copy the script for each cloned sprite...  At least I htink my kids would feel that way as much as I do. 
One thing that confuses me about protoyping is how to handle the specificity of the prototype.  So if Fred is your prototypical elephant, you can then define another elephant Clive, who is "like Fred, but different in particulars x, y, x".  And all subsequent elephants can be similarly defined.  But what if you realize that there are some things about Fred that you had imagined were generalities, but are actually really specific to him? Could you, for instance, "reparent" Clive and the other hundred elephants, and define a Fred derived from the new prototype? Thinking about this cognitively:  it may be the case that we arrive at abstract categories through particulars, but I think it's the case that our sense of categories shifts over time -- and that, for instance, I may have started out using Elrond as my prototypical elf but as I read broadly in the history of English, Nordic, and Celtic mythology, I came to think of elves as generally sinister and dangerous.  So Elrond has been gradually displaced as the prototype.*  It seems to me the prototyping leaves you with some tircky issues when that kind of evolution takes place.

[*sorry, we were watching Two Towers last night with the kids...]