Scratch

No, but they would be nice.

What I think is crucial-- and I think you've gotten this mostly right with Scratch-- is that there are important ways in which you can't make something simple just by putting most of it behind an "advanced" tab.  It matters sometimes how simple the system actually is, not just how simple it's pretending to be.

For instance one way it matters is that it affects the people who use it.  Scratch is at a level of complexity that I see as effective on two levels simultaneously: For the young & beginning users, it's at a level of complexity that's easy to get your brain around when you're not already familiar with these tools & concepts.  That's one.  The other is for the older & more experienced people who get involved with the project: The level of complexity that Scratch is at now is a level that an adult who's experienced with computers can get a solid hold of in just a day or two.  That makes anyone who comes here to play around instantly a qualified teacher.

If OTOH Scratch had a bunch of advanced features behind a superficial simplicity, when beginners came to the forums and asked, "how do you do X?", the advanced users would say: "Well that's simple! You set up an array of boolean values..."  Limiting the advanced users to a set of choices that's small enough that everyone understands the options increases the chances of a useful dialog.

Not that I'm weighing in against adding arrays.  I just think any additions should be carefully measured.  In the future I think it might make sense to splinter off an advanced scratch variant, as a decoy to host people's featuritis.  Speaking of which, your code is going to be released sometime?  It's in Squeak?

<3

Maybe it would be good to implement arrays with the following ideas:

1.  arrays are associative (even though Scratch today only has good numeric variable values, at least you could use a string constant as an index into an associative array)

2.  any variable can act as an array (more precisely, every variable *is* an array with a handy convention for use in a scalar context [see next item])

3.  extend the variable blocks to "set foo to [0] at position [0]", etc, with the convention that the current block without a position implies "at position [0]"

4.  type coercion on the index, so "1" is the same as 1, etc

5.  today, variables (and, hence, arrays) only hold integers; when variables are later extended to allow strings, arrays will get that too

6.  Any variable can be used as a value in a "set" block.  I'd like a way to set the value to be a reference to the variable, but at the moment I can't think of an approachable way to do that.  Anyhow, you could then have an array of arrays to build up arbitrary data structures.

Actually, the idea that a Scratch "array" can "wrap around" may be a good one, in terms of avoiding syntax errors and introducing "random" data that is outside of the array.  In other words, if you have an array of 10 items, the 13th item is just element #3.

While not perfect, and you should still encourage kids to do bounds checking in terms of accuracy, it does solve the problem of keeping it simple and has a certain elegance to it at the same time.  Indeed, I can think right off hand some cool "game" applications that might even take advantage of a self-wrapping array, and it simplifies some other algorithms as well.  And it keeps a Scratch project from crashing if the array is out of bounds.

So far, the only run-time error condition I've seen on Scratch is a division by zero error.  I don't know how to avoid that one if you are going to allow division at all, but that can easily be explained to children who understand the ideas of division at all.  It would be wise to keep it that way as well on all new block suggestions unless there is no possible work-around.

One thing I liked about BASIC arrays is that, by default, they were set with a size of 10 elements.  This is something that was very simple for new BASIC programmers to work with, and didn't require variable declarations.  There was a DIMension statement to establish array sizes if you wanted to get fancy (even with Dartmouth BASIC), and certainly advanced BASIC programs did extensive use of this statement.  IMHO Visual Basic has perverted the DIMension statement of "standard" BASIC beyond recognition and doing things that simply were never a part of the basic simplicity of the original BASIC.

I would also encourage the setting of array element counts to be something that is done dynamically with a block rather than some other more complicated menuing thing in the variable area.  And to make the element count something that can be set to a variable as well.  An example of this elsewhere was with the Applesoft (a variant of the 8-bit Microsoft BASIC) of the Apple ][ computer.  You could "redimension" arrays in the middle of your program (although it was often done only at the beginning), where it would truncate elements if the count became smaller, and added pre-initialized elements set to zero if you enlarged an array.  That was also an interpreted environment similar to Scratch in a small way.  The original Dartmouth BASIC threw a run-time error condition (or a compiler error) if you tried this idea, and there were other things that happened in other dialects of BASIC, although a run/compile error was very common.

Again, all of this is to define the behavior of this concept that would keep it simple enough for kids to use without having to learn all of the background theory about how  it actually works.