Scratch

scimonster wrote:

You know, I have no idea what you and Brian are saying in the replies?

Sorry!  Since xly is an adult, we have been using the Secret Language of Adults, the one parents use to discuss where Santa hid the presents. 

So.  Philosophy of OOP 101:

There are basically two points of view about what OOP is for.  (Like all such divisions, this one has fuzzy edges, of course.)  The point of view most prevalent in the Real World is that OOP is about information hiding.  That is, you're Microsoft, and you've hired 5000 mediocre programmers to work on a project (you can't just hire one good programmer instead because they're all working for Google), and you're worried that they're going to step on each others' toes.  So you make sure that each programmer writes an object class that keeps all its important information in private variables that nobody else can look at, and only accepts a small number of messages from other objects.

But BYOB isn't for huge teams of programmers; it's for kids messing around.  So our take on OOP focuses on simulation: If you're trying to tell a story with several different characters, it makes sense to write a program for each character rather than one big program that tries to keep them all straight.

As a result, nothing is really hidden in BYOB.  Sprites can have private variables, but some other sprite can use the OF block to get at this sprite's data -- even to modify it!

So, even though we have a particular programming style in mind, BYOB gives you the flexibility to invent other styles.  That's what xly is doing: inventing ways to use BYOB that aren't what we had in mind.

And what Jens and I are doing is pointing out possible pitfalls, mainly.  So for example xly suggested that an object need not have exactly one parent, that more complicated arrangements are possible.  And I replied that you'd better not have a situation in which A inherits from B and B inherits from A (a "cycle").  And also that what does have a more complicated arrangement isn't inheritance, but rather a variable in A whose value is (or contains) B, and a variable in B whose value is (or contains) A.  And you have to make sure to handle that situation somehow when you try to export sprite A.

Does that help?

scimonster wrote:

No, and I don't really care for messing around with BYOB.

Okay, I'll shut up now...  I hope you didn't take that as an insult!  I value messing around highly.

bharvey wrote:

I'm more nervous about the precedent of inputs to hat blocks altogether.  This sort of blurs the distinction between custom blocks and script-area scripts.  As I recall nXIII was arguing for that a while ago, but all else being equal it makes me nervous when a language provides two tools for the same task; I never know which I'm supposed to use when.

You're going to tell me about the pulldown menu in WHEN < > KEY PRESSED but that's not really an input; it doesn't bind a variable to whichever key you pressed.  (Maybe I shouldn't be giving nXIII ideas.    )

I saw my name more than once in a post and had to respond 

I think BYOB should use event listeners. Hat blocks (which must be modified) would provide a way of statically adding listeners, and (sorry...) a block would provide a method for adding them dynamically. The problem with this is, I guess, that it would be a fair amount more complex than the hat blocks and harder for new users to understand. However, it provides a lot of opportunities for advanced users.

I suppose I'm just trying to turn BYOB into JS, though....

EDIT:
Well, what I said was that there should be no reason to have two completely separate mechanisms for creating a sprite's blocks and its variables. One can use a variable with a closure as its value and there is no difference aside from invoking it. This also allows for users to dynamically alter a sprite's methods (I don't really see why you would want to do this, though...)

Last edited by nXIII (2011-02-07 15:09:45)

scimonster wrote:

nXIII, are you going to add that to Panther?

Event listeners? Nah... just learn JavaScript (trust me, you'll like it).

Last edited by nXIII (2011-02-07 15:24:19)

nXIII wrote:

[This also allows for users to dynamically alter a sprite's methods (I don't really see why you would want to do this, though...)

Oh, I used to do it all the time in Logo!  For example, you could write a TRACE procedure that takes a procedure as argument and modifies its definition to print messages on the way in and out.  Like the DEBUG blocks but for one specific procedure.

bharvey wrote:

That would be cool, but I'm the wrong person; I hate competitions and especially picking winners and losers.

But, didn't you suggest this already and not get any takers?  Why do you think it'd be different if I suggested it instead?

ic (I see)

14God wrote:

bharvey wrote:

That would be cool, but I'm the wrong person; I hate competitions and especially picking winners and losers.

But, didn't you suggest this already and not get any takers?  Why do you think it'd be different if I suggested it instead?

ic (I see)

Rather than a competition, I think we should try something similar to the Scratch design studio. Instead of having projects based on themes, I think we should make projects that take advantage of BYOB3's features. Of course, that would only be if people have time to make projects, which I'm not sure we do...

bharvey wrote:

shadow_7283 wrote:

I think we should try something similar to the Scratch design studio.

Or we could just do the actual Scratch Design Studio projects in BYOB! 

But BYOB can't upload to the Scratch site. 

Hi Xavier,

the BYOB version 3.0.9  that's linked to on the http://byob.berkeley.edu site is the current official version. Brian and I are in the process of designing and implementing new features for v.3.1, which will sport first class sprites and prototype based inheritance. We are frequently sharing internal experimental builds over a non-public mailing list which we're not making public on the website. However, since there is apparently a great deal of interest about this here, Brian has decided to share links to those experimental builds in this forum. So, after you download and install the currently official BYOB release you can download the latest experimental build and run either.

scimonster wrote:

Will the ability to read other sprite's personal lists be included?

Yup.  You can't do it by accident -- you have to use the OF block to ask for it.  But, yeah, nothing is really hidden.

But BYOB can't upload to the Scratch site.

Yeah, I was thinking we'd just mail them to the Scratch Team.  In plain unmarked wrappers. 

xly wrote:

one could imagine a 3-stairs Byob

This idea has come up before, in conversation with the Scratch Team.  They point out, correctly, that people would be confused if they downloaded a project that used blocks that didn't work under their settings.

bharvey wrote:

scimonster wrote:

[please keep your signature under 150 pixels vertical height]   Why does it keep growing?

No, the question is, what other kind of height is there, besides vertical? 

That's a good question. 

14God wrote:

scimonster wrote:

Will the ability to read other sprite's personal lists be included?

You can just use local variables as lists.

That's what I did, but that isn't first class.