Scratch

that sounds awesome! Can I help make it? I've been supporting for a while, sorta. I just haven't been posting on the Panther forums.

Ill have a go and post a link. It wont be finished so...

I know, im already making a OS, it has its own coding language so you can download apps or write them yourself!

Dunno yet, I am 1/2 way there in the coding. It will decompile a string at diffrent coding lines, and will reconise 3 commands. Im doing this so apps can be added easily!

ScratchReallyROCKS wrote:

I have a great idea for Panther. It would be the ability to name scripts and to call block numbers. I got this idea from BASIC (which I have been teaching myself by the way) because it has a 'goto (line number)' command which is really nice. Here's some mockup blocks I made:

http://img28.imageshack.us/img28/823/blockidea.png

Yes and no....

You see, I don't believe that the name block should be a command block; simply stated, it neither affects the code itself (control structures) nor the sprite (functions), so it should not be considered a control structure or a function. I will eventually redesign hat blocks completely, making them able to handle multiple events, handle no events, have return values, etc.

You are, however, discussing program labels; labels are generally considered "bad practice" as they can be dealt with (in higher level languages) in more elegant and neater (and easier to understand!) ways. The hat-block "redesign" I am referring to (and which may become a part of Panther) is more an incorporation of functional programming, rather than labels. I especially think that a block which looked something like this: "name this script []" would be incredibly confusing if it was synonymous to "label []."

one of my fave day-to-day thing about Panther is that the CYOB feature is absolutely brilliant for quickly creating great looking mockups 

sparks wrote:

one of my fave day-to-day thing about Panther is that the CYOB feature is absolutely brilliant for quickly creating great looking mockups 

I prefer to use  BYOB for that. As long as there is no programming needed, the only better thing about CYOB is that you get to choose the blocks color. BYOB only lets you use already existing colors + gray.

ScratchReallyROCKS wrote:

I have a great idea for Panther. It would be the ability to name scripts and to call block numbers.

About calling block numbers:  BASIC did this because it didn't have procedures -- the whole program was one big script and it made sense to jump around from anywhere to anywhere.  (It was also a huge source of bugs in BASIC programs, but at least it was clear what it meant.)  But jumping into the middle of a different script is really problematic.  What if that other script has local variables, for example?

Also, in BASIC you actually wrote the line number in front of each line.  Your way, implicitly numbering the blocks consecutively, works if you're jumping to block 3, but your user will have a hard time getting it right if s/he wants to jump to block number 472 of a script.

As for naming scripts, I think BYOB got that right -- the naming is part of the creation process, not something that happens while the script is running.
Or alternatively, since scripts are first class, you just use the general Scratch naming mechanism, namely variables.

EDIT:  One advantage to your idea is that the named scripts are visible in the scripting area all the time.  We went back and forth about this for BYOB: should custom blocks' scripts be visible as scripts?  The advantage is the same as the disadvantage: you can see your whole program at once.  It's an advantage if your program is short, but a disadvantage if your program is long.  On balance I think we got it right: make it easy to see inside a custom block but don't have them onstage all the time.  But sometimes I worry that this goes against a Scratch design goal that I generally agree with, which is to make everything visible because that makes it easier to learn what's going on in a project.  Your idea would be closer to that Scratch idea than ours.

Last edited by bharvey (2010-06-24 10:42:51)

So would that naming block be more like:

sparks wrote:

I was thinking more along the lines of
http://www.weebly.com/uploads/4/0/7/6/4 … 57.jpg?160
(sorry about hasty render)

though perhapse a little neater, and maybe a collapse arrow in the corner to show/hide blocks below it.

It might have a default name rather than a blank string argument too, like script1 etc.

But then you what if someone wanted to call only part of that, have it like classes and methods, the script is the class and inside that you have the methods.

sparks wrote:

markyparky56 wrote:

But then you what if someone wanted to call only part of that, have it like classes and methods, the script is the class and inside that you have the methods.

hm.... I suppose, but surely that's what broadcasts are there for...

Yeah... but it would make 1s1s projects easier. And more like a proper programming language, but thats not the goal of panther.

sparks wrote:

I suppose, at least in the original BYOB, the point of making blocks was that long scripts could be collapsed down into something smaller and more managable, as well as the ability to duplicate "Scripts" quicker.

Not entirely -- a big motivator (this is before I was on "the team" but I think this is true, at least this is a lot of what we were talking about at the 2008 Scratch conference) was the ability to write recursive procedures, which adds /hugely/ to the expressiveness of the language.  With recursion you can recreate any iterative control structure, but not vice versa -- there's no reasonable way to draw a fractal tree with REPEAT <n> TIMES and the like.

P.S. about named scripts, named parts of scripts, etc.:  I really vote no on named parts of scripts.  This is an invitation to spaghetti code without really adding anything to the expressiveness of the language.  If there's a logical reason for giving a name to part of a script, then that part should be a thing in itself (a script, or, dare I say it? a block).  As for naming entire scripts, there's no particular reason not to have that feature, but it strikes me as kind of a half-feature that screams out for the other half: being able to provide inputs to that named entity.  In other words, from my vantage point this feature sounds like a sort of poor man's [sorry for sexist cliche] BYOB, and if you're going to do it, why not just do (or steal) BYOB itself instead of half-reinventing it?  (This comment does not apply to nXIII's feature of extending the expressiveness of hat block conditions; that's a separate feature that seems very cool.  Although I'm not sure I understand how it differs from the combination of a generic WHEN <predicate> hat and the existing AND, OR, NOT blocks.)

P.P.S.  I'm a little nervous about posting the above because I'm afraid someone will take it as one-upmanship.  Believe me, I'm not feeling competitive with you folks; you're awesome and I just want you to have the cleanest possible design that expresses the capabilities you want to provide.