Scratch

I see your point about sharing, but disagree on the "messy entanglement".  I did a few "big" Scratch projects, whined about variables in the forums (because the huge list of variables gets so hard to manage in the "variable pane"). I made some suggestions about pull-downs for variables and renaming variables (still good ideas, I think) and then pretty much gave up on Scratch except for trying to be helpful by answering forum questions with simple demos.

I got excited about Scratching again after learning that the sensing block could "look" at another sprite's variables.  With some initial planning about what variables will be needed and which sprites will just need be able to "know" a variable's value and which will have to be able to change the value, it's possible to drastically reduce the number of global variables.
 
My latest effort is getting very big (I'm into writing video games), and I have only a handful of "globals".   I rarely even look at the variable pane after setting up the local variables that the current sprite will need.  Using the new "sensing" block obviously does away with the need for a lot of variables that had to be global so other sprites could "read" them,  but it also "exposes" custom "properties" (local variables).  I find this enormously convenient, and easy to use, instead of searching thru a list of globals, I only need to select the name of the other sprite of interest and pull down its list of goodies. 

It seems to me like this is a very nice intro to the idea of properties like other languages that young Scratchers will eventually work with;  "Set (mylocalVariable) to (enemyPlane.Velocity)".  It would be nice to be able to access the global variables in the same way.

I've mentioned the "danger" of globals in a couple of forum posts, advising folks to only use a global if you absolutely need to have more than one sprite be able to change the value.  I think a lot of Scratchers are using things like "Wait until (someglobal) < 1", and getting unexpected results because more than one sprite is able to change the global.  Tracking down "who" is changing it can really be difficult.

I haven't tried to do much sharing of Sprites, other than the "graphic" part, but it seems that if a sprite was looking at a global variable in its original project and you exported it and pulled it into a new project that didn't have that variable defined, you would be faced with the same broken "link".  A meaningful variable name or a  good comment could make it easy to "reconnect" the sprite into the new project.  Imagine pulling in a sprite, then looking at it when it doesn't work right and finding this broken sensing "reference":

Set (myLocal) to "Sense (?) of (?)"  'Comment: This variable stores the enemy plane's Velocity, used to decide if afterburners are needed to catch up.

or

Set (myLocal_EnemyPlaneVelocity) to "Sense (?) of (?)"

Even without a comment, figuring out what to "connect" to would be easy.

So, I like the new variable sensing ability a lot.  I'm happy with it as it is, I haven't yet seen the list of locals get so big that I'd want to be able to limit it.

-MrEd

Kevin, I like your idea of moving the variable-sensing block to the variables section and use the same pull-down menu interface. I agree that it would make Scratch more consistent.

I'm still not convinced, however, about read-only access to *every* local variable in every sprite. One concept I very much like in Scratch is being able to share and remix mostly everything you create. Not only whole projects but also sprites (I even think that being able to share single scripts would be a great benefit to Scratch).

The whole 'blocks' interface implies modularity in every layer of Scratch. You can simply snap an unsnap blocks and scripts to make your sprites do someting. Likewise you can exchange sprites (almost like 'blocks') by exporting them from one project and dropping them into another one. If your sprite accesses a global variable, this variable will automatically be generated in the target project if it's not already there. Not so, if you're 'sensing' other sprites' local variables. Therefore it can be pretty hard to map and keep track how sprites are interlinked to each other if you're extensively using variable-sensing. Especially if projects become big, i.e. use a lot of sprites.

Also, sometimes local variables are purely 'internal', such as counters, indexes or partial results. Exposing them (even read-only) doesn't seem wise to me, because it confuses the sprite's public interface. What I'd really love to be able to do is have one sprite 'ask' something of another sprite, and have the other sprite 'answer' a result.

in sprite1:
set variable to (ask 'something' from 'sprite2')

in sprite2:
when I'm asked 'something' answer (a number)

Per default the 'ask'-block could assume 0 as an answer, if the receiving sprite e.g. does not implement an answer.

This would let the programmer really control the sprite's public interface without the need for direct access to other sprites internals. It would also make creating big projects a lot easier, I think.

I like the Shared/NotShared idea, as it could help limit the list and what is intended would be clear to beginners. 

I haven't experimented to see what an "unconnected" Sensing block looks like or what it returns (I'm guessing "zero"). 

Perhaps the reuse issue could be addressed (at least partially) by highlighting an "unconnected" Sensing block in some way.  Something like the way Fatal errors cause a script or block to get a red "halo" might work.  Flashing yellow halo around the block?

Off topic a bit:  It bugs me that a Fatal error just locks the script without letting the programmer know what is wrong.  The first time I encountered a Fatal error, I'd constructed a loop that caused a variable to "blow up".  The problem was pretty obvious, as the variable display was on screen and I could watch it go from a reasonable number, to really big, to scientific notation until it finally "blew".  I'm sure new programmers will run into divide by zero errors, and end up wondering why their script went all red. 

It would be nice to have a message (maybe like a tool-tip) for the unconnected block "warning" (and the Fatal error).  Jen's concern that re-connecting may be difficult is correct, but I think the same could be true of Global variables that a Sprite brings into your project.  What happens if you have already used the name of the new global (with some other meaning) or it isn't clear what the new Global represents?  In either case (Sensing block or Global variable), the only way I see to make things easier is to use descriptive variable names or put in good comments.

-Mr Ed

Jens's idea, to have "ask <something> from <sprite>"  and
"When I'm asked <something>"
....
     reply <value>

is a nice way to do a sort of function call.
It could be combined with Paddle2See's Shared/NotShared checkbox (though perhaps the checkbox would need a different name), by having the Shared checkbox equivalent to a script 
     When I'm asked <variable name>
     reply <variable>

Heybrian, I don't understand your post. Could you please explain what you mean.

Paddle2see wrote:

I already encountered something strange trying to import a sprite that used global variables.  It came in okay, and it created the globals to go along with it.  But none of them worked right; they acted like two sets of local variables with the same names.

Yeah, I noticed this, too. I found out, that saving the project to disk resolved this issue and made the globals work alright.

Kevin, you're absolutely right about my suggestion basically being a call for a simple function feature (without parameters) in Scratch. Allowing sprites to 'respond' / 'answer' to requests by other sprites could not be restricted to answering its local variables, but also let them answer derived computational results, i.e. one sprite could have the script for a certain algorithm and provide this knowledge to other sprites.

EdnaC wrote:

I'd would be interesting to get some more input from the developers on "where we would go with Scratch if you dreamers can figure out a reasonable way to implement it" vs "stuff you shouldn't even bother fantasizing about".  We could concentrate on helping to figure out intuitive ways to implement the stuff that is likely.

I agree with you 100% on this, Mr. Ed.  While the academic exercise is fun, how much of what we talk about is even in the developer's vision of Future Scratch?  Some feedback from the develpment team would be very helpful here.

I think that Jens's "ask" and "answer" blocks are a good metaphor for function calls—clearer to kids than the broadcast/receive.  One problem is that there must be exactly one "when I'm asked" script in a sprite for any question that a sprite can be asked.

Some things to think about: 

Should questions and messages be the same or different name spaces?  Different programming languages have taken different approaches to this question.  In some (like FORTRAN), functions that return values are distinguished from procedures that don't return values.  In others (like C), all functions and procedures are in the same name space, and in still others (like C++), the type of returned value and arguments is effectively part of the name.  My initial, gut reaction is to agree with Jens that messages and questions should be separate name spaces.

Should you have to fall through the "when I'm asked" script to return an answer, or should you be able to "answer" from any part of the script.  This is essentially the question of whether there is a "return" statement in the language.  Personally, I find that "return" statements make for simpler, cleaner code, but it would be easy for beginners to forget to put in "answer"  blocks. Perhaps the best compromise is to have Jens's idea of a built-in "answer" at the end of the the "when I'm asked", but to allow the programmers to have other answer blocks inside.

Jens wrote:

You know, this kind of discussion is exciting, because since Scratch is now (officially, it seems) open-source, we might actually experiment with implementing some of these concepts ourselves, once we feel convinced by the results of this "academic excercise".

That's a very good point that somehow slipped my mind.  I'll start learning SmallTalk immediatly!

Hey Mr. Ed,

I don't know of any 'open source team'. (wanna join? <nudge>, just kidding...)

Myself, I'm not about to develop anything, let alone a different version of Scratch. I admire the 'real' Scratch by MIT way too much, and have way too little time on my hands to dive into a big programming project (besides knowing way too little about real programming anyway).

But I do love participating in discussions like this one with bright people like you    from around the world, and I believe the 'Advanced Topics' section in the forums is just the right place for this. I've also seen discussions like this one lead to new ideas within Scratch itself, though this shouldn't neccessarily be their primary objective.

Another thing that intrigues me is not just to speculate about the feasibility of some wild idea, but to actually go ahead and try it for real. That's why I enjoy playing with the Scratch source code. I don't want to (and certainly cannot) make Scratch any better than MIT, but I love experimenting. After all, what harm can be done by that?

And I found fiddling with the source code to be far easier than I expected. Since it is all Squeak, everything can be read, evaluated, inspected and modified on the fly while the system is up and alive, without any compile-link-run cycles. If there's an error, nothing will blow up in your face or kill your computer. Instead the worst that'll ever happen is a friendly pink walkback window notifying you about which part of your code it doesn't understand, and letting you fix that immediately *in itself* without even having to restart the application afterwards. Besides, there are no hidden 'secrets' in the source code accessible only to initiated gnostics, but absolutely *everything* is there for you to read and understand, even the virtual machine. This is a fascinating (and courageous) degree of openness I have observed only in very few other so called open-source projects.

To sum it up, I'd claim that discussing Scratch-ideas and playing hands-on with the Scratch source code is one way to express appreciation for Scratch!

Having said this, any more thoughts about localized data-retention, public visibility of local/private variables or function-calls? ...

MrEd, there are several threads on layers and ways to improve them on the forum.  You might want to search the forum for them and add your thoughts to that discussion.

I think that Jens's ask/answer mechanism is a good way to introduce the notion of function calls without needing all the GUI for custom blocks (though custom blocks are also a good idea).  The reply from an 'answer" need not ever be a variable.  For example

say <ask sprite what quadrant?>


when I'm asked what quadrant?
    if x position> 0 and y position >0
       answer 1
    if y position >0
       answer 2
    if x position >0
       answer 4
answer 3

MrEd wonders if the MIT Scratch team is likely to adopt the ask/answer proposal.

We make Scratch design decisions as a team, and my opinion is just one input into the decision process. That said, here's what I think.

Personally, I love language design, I love object-oriented languages, and I enjoy thinking about possible language features even if they never get implemented.

But in deciding what features to add to Scratch, I'm cautious and conservative. Scratch is wildly successful at getting a wide range of people to program, including many who do not think of themselves as "programers" and who would have no interest Java, Python, Squeak, C++, or any other professional programming language. It would be a shame to introduce features that make Scratch less fun and friendly to such people, even if those features would be useful to more advanced users. After all, there are many cool languages available once you've discovered that programming is fun, but Scratch is one of the few that welcomes beginners and invites them to make that discovery.

Many of us professional programmers got started by playing with BASIC as kids. Today we consider BASIC a "badly designed" programming language but I had fun with it. In fact, BASIC was actually a great intro to programming. It's perfect for writing programs of a few dozen lines. You can get started quickly and then learn additional commands incrementally. It's model of computation is very clear. And by the time you hit it's limitations, you know enough both to learn your next programming language and to appreciate the additional features that make it easier to write larger and more modular programs.

Scratch is the modern equivalent of BASIC. It lacks many of  the features found in modern object-oriented programming languages, such as being able to send a messages to specific a object and get its reply (which is what Jen's "ask/answer" proposal does), being able to control the visibility of variables and methods, classes, inheritence, exceptions, and so forth. Those are all powerful features, but I dont think they belong in Scratch.

However, as I said, I enjoy thinking about potential language features even if they never get implemented, and I hope many of you do, too. I value these discussions, and we do sometimes incorporate ideas from such discussions into Scratch. In fact, the block that reports a sprite's instance variable grew out of a forum discussion.

So, discuss on!

  -- John

Last edited by johnm (2008-01-20 10:40:25)

Thanks, John, for your clarification on terminology. I assumed 'open source' to denote just readability of source code (like an academic paper) regardless of its license, i.e. not neccessarily including the right or feature to mod it into something else. I still think that letting others look look over your shoulder and allowing them to discuss your code in public is about the boldest and most daring step a programmer can undertake!

By the way, I started out with BASIC, too, and it got me hooked onto programming as well!

What got me starting this thread was actually not a wish for an 'ask/answer' command block pair, but my ambivalence towards the existing "sense a sprite's local variable" mechanism and its side-effect, which is that it reduces shareability of sprites between Scratch-projects.

One way to have a sprite retrieve another sprite's state would be to let the target sprite decide if and what it wants to answer, instead of directly accessing its internals.

The (only) method to accomplish this before the new "variable-sensing" block was introduced, was to broadcast a message to all Scratch objects and let the one of interest 'answer' to a global variable. This method still works perfectly well, the downside being the need for two globals: a (global) message name and a global variable.

Now there is an additional method (the sensing block), so nothing is lost and much is gained. The new method is powerful, because it eliminates the need for both, the global variable and the message name, in order to exchange data between sprites. The downside is, that this method ties two sprites together in a way, that makes it hard to plug them apart and remix them.

It's sort of like glueing Lego bricks together.

A third way to exchange data between objects would be to allow sprites to answer to messages other than by accessing a shared/global variable (my initial 'ask/answer' thought). It occurs to me now, however, that letting one sprite direct a 'question' towards another wouldn't solve the 'shareability'-problem, because it still needs the target sprite to be 'introduced' (visible) to the requesting one first, which ties both together in exactly the same manner that I'd like to see resolved.

So, I guess, if one wanted to implement a way for sprites to exchange data avoiding a shared variable or a direct link, one way to do it might be to introduce 'globally answerable questions' to Scratch. Something like:

     <ask 'a question' to all>

This would be a yellow, round numerical reporter block of the 'control' category, since it would be a 'controlled' value. It would correspond to:

     <when I'm asked 'a question'
     ...
     answer (aNumber) >

The downsides of such a mechanism would be manyfold:

1) It needs an additional command block (the new event-hat).
    Plus, as Kevin pointed out,
2) there's a namespace decision to be made, and
3) there's the problem what to do if more than one script answers to a question.

In sum, the regained modularity would lead to an increased complexity, and therefore might not be worth it (but isn't it fun to fantasize about its possible other benefits nonetheless?).