Scratch

I have the same ability to contact the Scratch team that you all do.  They read the forum, and they read mail sent to scratch-feedback@media.mit.edu

As for long scripts, they don't slow things down at all.  What matters is how many blocks are being executed at once, not how many are sitting around doing nothing at the moment.

The difference between  "forever if <x>" as a single block and "forever" "if <x>" is that it is possible to implement the "forever if <x>"  as "forever" "wait for <x>" and it is possible for "wait for <x>" to be evaluated only when one of the variables involved in <x> are changed.  I don't know exactly how the "wait for <x>" is implemented in Scratch (perhaps Jens could look through the source code?), but if it is done in the most efficient way the "forever if <x>" construct could be substantially faster than "forever" "if <x>".

kevin_karplus wrote:

The difference between  "forever if <x>" as a single block and "forever" "if <x>" is that it is possible to implement the "forever if <x>"  as "forever" "wait for <x>" and it is possible for "wait for <x>" to be evaluated only when one of the variables involved in <x> are changed.  I don't know exactly how the "wait for <x>" is implemented in Scratch (perhaps Jens could look through the source code?), but if it is done in the most efficient way the "forever if <x>" construct could be substantially faster than "forever" "if <x>".

I dont understand either/

[blocks]<forever if> condition
<end>[/blocks]

can be implemented as

[blocks]<forever>
<wait until> condition
<end>
[/blocks]

Last edited by pasta3049 (2008-01-09 11:15:17)

pasta3049 wrote:

[blocks]<forever if> condition
<end>[/blocks]

can be implemented as

[blocks]<forever>
<wait until> condition
<end>
[/blocks]

ok, i get it now. so Kevin was saying how the wait untill block makes it slower. that makes since

MITscratcher, you have it backwards.  The "wait until" block has the potential to have less impact on the computer than an "if block" since it only needs to be evaluated when any of the variables it is looking at changes, while an if block would keep getting tested over and over.

Anything that can be done with "wait until I receive" could be done with variables also.
Some of the other uses proposed for <I receive> (in "if" or "repeat until") might not be easy to do with variables, but they might also be hard to implement in the underlying scratch interpreter, also.

Oh, I agree that a "wait until I receive" command would be very nice to have.  It just isn't quite as easy to implement as most of the other suggestions made here, and a lot of what it is wanted for can be done (albeit clumsily) with the existing commands of scratch.

Global variables do not slow down programs, though a busy-wait loop (using an "if" inside a forever block, instead of waiting for a condition on the variable) can slow a project down a lot.

If properly implemented, a "forever if" block should put less load on the computer than forever and if separately, since it translates to
   forever
      wait until <condition>
      ....
and "wait until" can be implemented to use less CPU resources than "if".  I don't know whether the Squeak or java implementations of scratch actually do implement "wait until" efficiently, or if they use inefficient busy waiting.

Heyb,
Making variables Global doesn't cause a "lag" issue; Making every variable in the project a global would be perfectly OK as far as the computer is concerned, because what humans call a variable is just a storage location as far as the computer is concerned.  The problem with Global variables is that any script in any sprite can not only read the variable, but can also change it.

Suppose a programmer was working on a big project and decided to add "damage" to a Sprite.  He (or she) could make a Global variable named "Hero_Health", and add a script to the "Enemy":

If touching <"Hero">
   change Hero_Health by -1

Then, the programmer has to stop Scratching to eat dinner, do homework or whatever.  When returning to the project a day later, he may forget that the Enemy already can damage the Hero, and add a script to the "Hero":

If touching <"Enemy">
   change Hero_Health by -1

This is a simple example, but shows why Global variables should be limited.  It isn't the computer that gets confused (computers don't get confused!), the problem is that Global variables can confuse the programmer.

By making a variable Local ("for this sprite only"), you keep any other sprite from being able to change it.  Local variables "belong" to their "Sprite", other sprites can sense the variable's value (the number it stores), but they can't change it.  In the example, the Enemy could sense the Hero's health, but only the Hero could change the variable.

This makes your job easier, especially as the project grows and lots of variables are needed to store (and change) information.  Keeping variables local makes it easier to find the problem if a variable is changing in a way the programmer didn't expect.

-MrEd

Changing variables from local to global in scratch is not currently possible. You have to create a new variable and find every instance of the old one and change it.  This is incredibly difficulty and time-consuming in scratch (since each set block has to be dragged out and a new one dragged in, and there is no search capability).  That is why the suggestion is often made to provide a way for changing whether a particular variable is global or local, or for renaming a variable (which is equally difficult to do in the current version of scratch).

No, neither local nor global is "better", but they are different. 

Local variables can only be changed by one sprite.  This makes debugging easier and keeps variables organized.  For example, it is much easier to have a "health" variable for each sprite that the sprite keeps track of, than to have large numbers of global variables.

Global variables can be changed by any sprite.  This makes them useful for inter-sprite communication, where one sprite sets the variable, then does a broadcast to let the other sprites know.

Both types of variables are useful, but in different ways.