I would like to request the ability to pass arguments to script invocations.
This is obviously an advanced programming construct, but it would be great to be able to define a chunk of script code once, say in the stage, such that it belongs to (applies to) all sprites and then be able to reuse it.
Without this, it makes the code messy having to copy the same chunk of code from sprite to sprite and change a block or two with some different numbers.
Many, many thanks!!!
Offline
There are "global" variables that you can assign values to, and use some of them for parameter passing. I know this is ugly and is prone to introduce bugs if you have multiple "subroutines", but it is one way to pass parameters. And then you can use the "Broadcast <message> and wait" as a sort of subroutine invokation device. This has been done on several other Scratch scripts, including some of the examples that are installed with Scratch.
So, yes, you can have just one block of code that can be invoked from multiple sprites and locations throughout a project, but you do have to get a little bit creative.
Offline
Robert,
In order for Scratch to be effective in teaching kids programming, constructs such as Logo's ability to create named procedures with multiple parameters is essential. In Logo, which also came out of MIT, you could simple create a "to square :sideLength" that creates a square with the side length passed in. This in turn can be called from other "to" code creating higher order functionality.
Scratch team:
Please consider functionality like this for a future release.
Thanks!
Offline
I would have to agree that a formal procedure call would be incredibly nice to have. I'm just trying to suggest a current "hack" to attempt something along this line of thought.
I'm fighting one of those "procedures" right now in one of my scripts.
Offline
Roberth wrote:
I would have to agree that a formal procedure call would be incredibly nice to have.
Pragmatically, it's more than nice-to-have. Without it, we're teaching kids to do one of the Great Evils of programming: repeated cut-and-paste of code. Unfortunately, I know many professional programmers who think that's a fine way to do business.
Offline
Agreed, without some sort of function or subroutine capability it's severely limited in the scope of teaching "real" programming.
You could simplify things a bit, in that every routine called would use the sprite it was called from to operate on (a psuedo-oo kind of thing).
Right now I see lots of projects (including mine) with numerous sprites all with the same code cut and pasted.
Offline
An easy start of subroutines could be a macro-like feature where an arbitrary group of blocks (maybe a complete script?) could be put into a graphical wrapper and reused as a whole. I'm thinking of a "define" block something like the "when [] key pressed" control, but it would instead be "define block named []". A companion "use" block would be shaped like most of the blue motion blocks (notch at the top, bump at the bottom) with a label like "use block named []".
Just like variables, the define/use blocks could be scoped to a sprite or scoped globally.
To get formal parameter stuff, I think you need a new kind of variable (a local variable, not scoped to a sprite or globally). Still, I think it could reasonably done while still maintaining the simple Scratch graphical paradigm
Offline
wjcarpenter wrote:
Without it, we're teaching kids to do one of the Great Evils of programming ....I know many professional programmers who think that's a fine way to do business.
Lighten up - computers are tools - not religious icons. The really dangerous programmers are the ones who think orthodoxy is more important than actually creating something that works.
Offline
DrJim wrote:
The really dangerous programmers are ....
Sorry, did you mean to be talking about me? I'm not sure since nobody has ever called me a "dangerous" programmer (except maybe the test team :-).
Offline
I found Dr. Jim's comment a little off the mark. "Something that works" is often not good enough---it has to continue to work despite changes in the underlying operating system and compilers, and to be maintainable. Without procedures and comments, scratch programs are limited to rather toy examples---fun to play with, but not as good a teaching tool as it could be.
Offline
kevin_karplus wrote:
"Something that works" is often not good enough---
It is necessary (!) - and occasionally sufficient. ( Not very often, of course.)
My point, however, was more to suggest that Scratch is more a way to get kids interested in general programming concepts - not to actually turn them into hard core programmers.
P.S. - In most test teams I've been on - "dangerous programmer" is redundant, at least after the first couple of days. :-)
Last edited by DrJim (2007-06-03 14:24:03)
Offline