Scratch

itsme213 · 2008-02-09 22:55:01

====================
Any guess on time line for any of the following related set:

1 other data types (just Strings and Sprites, see below)
- Strings approximate enumerations, far nicer to do
IF <color = RED> than IF <color = 7>
- strings for the same reasons that costumes, sounds, sprites use names, not numbers
- strings to parameterize SAY/THINK blocks, etc.
SAY <name> of <person>
- strings to utilize text-to-speech etc. (when available)
- even if no library of string operations is provided at first, it is still a winner

- Sprites data type: to enable lots of other powerful things

- booleans are OK as-is with C-style: 0/non-zero, 0/1, nil/non-nil
but boolean-blocks could "know" this and accept plain variables e.g.
IF I_Am_Happy rather than IF (I_Am_Happy = 1)
IF My_Pet rather than IF (My_Pet != nil)

- can be done with NO type declarations, or just for event/method signatures

- needs NO static type-checking to be intuitive to users e.g.
a valid Sprite as Boolean => true; null sprite => false
an empty String as Boolean => false; non-empty string => true
a valid Sprite as Number => 0; null sprite as Number => 0
any String as Number => 0
a number 0 as Boolean => false; other numbers => 1
any Number as Sprite => null sprite
any String as Sprite => null sprite

2 parameter passing with broadcast events
- PLEASE treat functional abstraction as a basic programming technique

3 dynamic sprite cloning (shallow copy not including linked sprites)
- clone <sprite> block, dynamic equivalent of today's "duplicate" menu
- with current sprite-local variables this can STOP most poor copy/paste
Kids DO enjoy making things work, but NOT debugging 5 out-of-sync copies.
- might make good use of method-local variables if available
- can sufficiently approximate OO classes for most uses

4 directed method calls with parameters and returns
SEND <message> TO <sprite> [RETURNS <local name>]
needed for dynamic sprite cloning: you cannot statically encode info in event name
enables lots of other powerful stuff
would benefit from method-local variables like RETURNS <local name>

==============
It could be useful to have a control block:
WHEN <variable> [OF <sprite>] CHANGES
That way one sprite can react to changes in variables (either global or of specific other sprites). A Forever block that reads the variable does not quite cut it.

===============
Variables should be re-nameable without deleting them.

===============
Screen space: it would be nice to be able to collapse and expand code blocks, and to re-size the sub-panels. All kids today understand these operations from windows.

===============
Does open-source Scratch have an MIT license? Where is it downloadable?

Thanks for a wonderful project. Scratch is great. Please try to find ways to make the core features smaller and more powerful, without overly sacrificing usability.

Mayhem · 2008-02-10 03:48:04

itsme213 wrote:
It could be useful to have a control block:
WHEN <variable> [OF <sprite>] CHANGES
That way one sprite can react to changes in variables (either global or of specific other sprites). A Forever block that reads the variable does not quite cut it.

This one is pretty easy to replicate.

Simply include a broadcast at the source of the variable change (they don't change on their own, after all).

Thn you can have "When I recieve" instead of "when variable changes"

kevin_karplus · 2008-02-10 17:26:16

Mayhem wrote:
itsme213 wrote:
It could be useful to have a control block:
WHEN <variable> [OF <sprite>] CHANGES
That way one sprite can react to changes in variables (either global or of specific other sprites). A Forever block that reads the variable does not quite cut it.
This one is pretty easy to replicate.

Simply include a broadcast at the source of the variable change (they don't change on their own, after all).

Thn you can have "When I recieve" instead of "when variable changes"

I think that the idea was to reduce the need for huge numbers of messages.
It would not be difficult to change the definition of the "set variable" and " change variable" blocks to send a message to any "when variable changes" hats, and it would avoid the bugs that would result form forgetting to send a message every time you change a variable.

Jens · 2008-02-11 05:55:23

Hi itsme213,

itsme213 wrote:
Does open-source Scratch have an MIT license? Where is it downloadable?

You can find the Scratch source code here:
http://scratch.mit.edu/pages/source

The Scratch application itself has an MIT license, the Scratch source code comes with a more restriced license chiefly aimed at avoiding confusion between the official Scratch product maintained by MIT and independent variants of the Scratch source code while keeping the source code open, and apparently also directed at keeping third party derivate works based on Scratch "open source" and free of charge.

The source code version is almost exactly the same as the product, and if you use it "out of the box" you can create perfectly real, shareable Scratch projects with it, and edit every project created by the official Scratch application or downloaded from the website in it. The only thing missing in the source code is the ability to upload projects to the website, which I personally appreciate, because it would open the website to all kinds of incompatible projects created by experimental versions.

The official Scratch application consists of a permanently 'locked down' Squeak image, which cannot be unlocked again (unless you've got the key or hijack one of the few remaining walkbacks), whereas the source code image sports an extremely convenient way to switch between user and developer modes. From what I've seen so far, there are absolutely no performance differences between both versions, and the published source code is really in no way inferior to the product, in other words, it's a genuine treasure-trove!

I'm certain that anyone who has ever programmed in a Smalltalk-80 environment will devour the Scratch source code and the developer's comments like a bestselling suspense-novel, and fall in love with Smalltalk all over again. Once again I'm wondering why anybody would want to work in any other programming language, when instead they could cast magic in Smalltalk...

BTW: Are you the same person as itsme123 on the Squeak mailing lists? just wondering...

itsme213 · 2008-02-11 18:23:32

kevin_karplus wrote:
I think that the idea was to reduce the need for huge numbers of messages.

Correct. For roughly the same reason I think providing [the option of] automatic setters on sprite variables may not be a bad thing.
SET <variable> OF <sprite> TO <value>

Trying to do this with events gets horribly messy very fast.

itsme213 · 2008-02-11 18:38:56

Jens wrote:
... and apparently also directed at keeping third party derivate works based on Scratch "open source" and free of charge.

Hmm. All the rest seems correct, but that part seems very non-MIT in spirit. Unfortunate, imo.

BTW: Are you the same person as itsme123 on the Squeak mailing lists? just wondering...

Yes.

Jens · 2008-02-11 23:54:03

itsme213 wrote:
Hmm. All the rest seems correct, but that part seems very non-MIT in spirit. Unfortunate, imo.

I've been also wondering what's the reasoning behind this.

chalkmarrow · 2008-02-12 11:35:21

I think the reasoning is that they would prefer that third parties not charge for various flavors of Scratch. This seems consistent with the MIT spirit to me, actually.

Jens · 2008-02-13 01:33:03

Aha, now that does indeed make sense.

Lucario621 · 2008-02-28 16:51:25

itsme213 wrote:
- strings to parameterize SAY/THINK blocks, etc.
SAY <name> of <person>

Well you can do this. Put "(Your variable or true false thing)"in a say or think block and it will work.

kevin_karplus · 2008-03-01 17:51:53

Lucario621, the current capabilities of say/think blocks are rather limited. A lot more could be done if we had string variables and string expressions.

JSO · 2008-03-02 03:37:12

itsme213 wrote:
It could be useful to have a control block:
WHEN <variable> [OF <sprite>] CHANGES
That way one sprite can react to changes in variables (either global or of specific other sprites). A Forever block that reads the variable does not quite cut it.

Good idea, but you can try this without that feature.

when green flag clicked
forever
set memory to variable ----> memory is a local variable
wait until not memory=variable
...

Scratch

archived forums

#1 2008-02-09 22:55:01

[Long] Advanced features, when <Variable>Changed, screen usage, more

#2 2008-02-10 03:48:04

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

itsme213 wrote:

#3 2008-02-10 17:26:16

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

Mayhem wrote:

itsme213 wrote:

#4 2008-02-11 05:55:23

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

itsme213 wrote:

#5 2008-02-11 18:23:32

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

kevin_karplus wrote:

#6 2008-02-11 18:38:56

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

Jens wrote:

#7 2008-02-11 23:54:03

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

itsme213 wrote:

#8 2008-02-12 11:35:21

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

#9 2008-02-13 01:33:03

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

#10 2008-02-28 16:51:25

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

itsme213 wrote:

#11 2008-03-01 17:51:53

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

#12 2008-03-02 03:37:12

Re: [Long] Advanced features, when <Variable>Changed, screen usage, more

itsme213 wrote:

Board footer