Scratch has a number of things that have enhanced the programming environment. But it's a pain in the butt to track clones, or duplicate code from one sprite to another. A solution to this would be Object-Oriented Programming. If you are not familiar with it, Object-Oriented programming would add two things: classes and objects. Think of classes like this; anything in the class has a set of functions (introduced in 2.0) including other classes. An object is like a sprite; but it inherits the code of a class. Not only would this make it easier to duplicate code across many sprites, but with objects, we would be able to track clones (as an object under a class defined by the mother sprite or by the user (if possible)). This would be very useful; because you could see the X and Y of each clone as well as what number clone it is (#1, #2, #3, etc.). Each clone could be operated by a different sprite using these variables, or you could select a certain number to do something while the others do something else.



__________________________________________________________________________________________________

Responses to comments:

kilokreeper wrote:

Support, but only if it's toggleable. For example, a kid new to scratch would be confused. So by default, it's off, but people who understand it can use it.

Yes; by default clones are as they usually are. But with the addition of a

class[class1 v]

or

new object [class1 v]

block, the clones would become objects and you could put classes in.
I'm thinking of classes being in the sprite menu but with a graphic that shows clearly that they are a class.

Yes. Actually having scripts separated somewhat from sprites would make scripting much cleaner and easier as well. See my topic about pushing for a usability cleanup for projects of some scale.

Support, but only if it's toggleable. For example, a kid new to scratch would be confused. So by default, it's off, but people who understand it can use it.

OOP doesn't need classes. There's other ways to do OOP, like the Prototyping-style OOP in Self and JavaScript.

kilokreeper wrote:

Support, but only if it's toggleable. For example, a kid new to scratch would be confused. So by default, it's off, but people who understand it can use it.

Nooooooooooooooo that won't be nessecary
Yes, a person new to Scratch wouldn't understand, but they wouldn't understand lists either, or broadcasts or custom blocks, would they?

kilokreeper wrote:

Support, but only if it's toggleable. For example, a kid new to scratch would be confused. So by default, it's off, but people who understand it can use it.

What if a new Scratcher remixes a project containing these blocks?
What if Earth flies into a black hole?

support 100%. this would be incredibly usefull. please implement this scratch team!

kilokreeper wrote:

Support, but only if it's toggleable. For example, a kid new to scratch would be confused. So by default, it's off, but people who understand it can use it.

Semi-support for this.

Jonathan50 wrote:

Yes, a person new to Scratch wouldn't understand, but they wouldn't understand lists either, or broadcasts or custom blocks, would they?

Lists, broadcasts, and custom blocks are a necessary sacrifice, my friend. The problem is learning to draw the line.

As @DaSpudLord said, in my opinion this is too complicated for Scratch, so No Support

BookOwl wrote:

As @DaSpudLord said, in my opinion this is too complicated for Scratch, so No Support

I disagree, it sounds just about as complicated as navigating a folders on a computer. Which isn't hard once you spend more than 5 minutes doing it, honestly

Essentially as I imagine it for scratch, sprites would be organized in a folder type hierarchy with the upper level featuring a button to show it's… um… ‘branches’ full of sprites

DaSpudLord wrote:

kilokreeper wrote:

Support, but only if it's toggleable. For example, a kid new to scratch would be confused. So by default, it's off, but people who understand it can use it.

Semi-support for this.

Jonathan50 wrote:

Yes, a person new to Scratch wouldn't understand, but they wouldn't understand lists either, or broadcasts or custom blocks, would they?

Lists, broadcasts, and custom blocks are a necessary sacrifice, my friend. The problem is learning to draw the line.

That's a pretty arbitrary point at which to draw the line

especially when a simple explanation is all it takes for it to be understood :^

DaSpudLord wrote:

Jonathan50 wrote:

Yes, a person new to Scratch wouldn't understand, but they wouldn't understand lists either, or broadcasts or custom blocks, would they?

Lists, broadcasts, and custom blocks are a necessary sacrifice, my friend. The problem is learning to draw the line.

No. If you draw the line you will never learn anything new.

Jonathan50 wrote:

DaSpudLord wrote:

Jonathan50 wrote:

Yes, a person new to Scratch wouldn't understand, but they wouldn't understand lists either, or broadcasts or custom blocks, would they?

Lists, broadcasts, and custom blocks are a necessary sacrifice, my friend. The problem is learning to draw the line.

No. If you draw the line you will never learn anything new.

At some point, the user will move on from Scratch (if programming is truly something they're interested in) and they will learn more. But if they can't learn Scratch because it's too complicated, then they don't get that early boost in programming that Scratch provides. I'm not drawing the line to prevent experienced users from learning, I'm drawing the line to allow new users to learn.

DaSpudLord wrote:

Jonathan50 wrote:

DaSpudLord wrote:

Jonathan50 wrote:

Yes, a person new to Scratch wouldn't understand, but they wouldn't understand lists either, or broadcasts or custom blocks, would they?

Lists, broadcasts, and custom blocks are a necessary sacrifice, my friend. The problem is learning to draw the line.

No. If you draw the line you will never learn anything new.

At some point, the user will move on from Scratch (if programming is truly something they're interested in) and they will learn more. But if they can't learn Scratch because it's too complicated, then they don't get that early boost in programming that Scratch provides. I'm not drawing the line to prevent experienced users from learning, I'm drawing the line to allow new users to learn.

-.- Scratch is supposed to have a high ceiling

Jonathan50 wrote:

DaSpudLord wrote:

...

-.- Scratch is supposed to have a high ceiling

And it's also supposed to have a low floor. Scratch already has a pretty high ceiling, as seen by the many complex projects out there. The ST hates raising the ceiling at the cost of also raising the floor.

DaSpudLord wrote:

Jonathan50 wrote:

DaSpudLord wrote:

...

-.- Scratch is supposed to have a high ceiling

And it's also supposed to have a low floor. Scratch already has a pretty high floor, as seen by the many complex projects out there. The ST hates raising the ceiling at the cost of also raising the floor.

Technically, every turing complete language (Python, JS, C, C++, Java, Lisp, Assembly and many, many others) all have the same “high ceiling”. The difference is how easy it is to reach. Scratch makes it really hard to get to the high ceiling.

BookOwl wrote:

DaSpudLord wrote:

Jonathan50 wrote:

DaSpudLord wrote:

...

-.- Scratch is supposed to have a high ceiling

And it's also supposed to have a low floor. Scratch already has a pretty high floor, as seen by the many complex projects out there. The ST hates raising the ceiling at the cost of also raising the floor.

Technically, every turing complete language (Python, JS, C, C++, Java, Lisp, Assembly and many, many others) all have the same “high ceiling”. The difference is how easy it is to reach. Scratch makes it really hard to get to the high ceiling.

But what is more important- getting inexperienced users onto the low floor or getting experienced users to the high ceiling? And is it worth raising the floor to make the ceiling closer so users can touch it? Personally, I believe the floor is fine where it is.

How does adding a feature raise the floor? Anyone can just ignore the feature or ask questions and learn about it…

Firedrake969 wrote:

How does adding a feature raise the floor? Anyone can just ignore the feature or ask questions and learn about it…

So you're saying we could add 1000 blocks? It doesn't make a difference, just ignore them or ask questions…

Woah, slow down there. I never said that, so don't attack a straw man, lol (or use a slippery slope - both at once, maybe?). It depends on the blocks, their purposes, their functions, etc…