1. First of all, to people arguing against DaSpud, having programming knowledge doesn't give you the right to suggest concepts which not many people understand. You, Chibi (or should i call you Matoran?), even said that the current main community focus of Scratch is mostly not coding.
   It may have various projects where people do formally program, but most of them still not have as much programming as an ideal programming community, like most text-based programming communities, would have.
   
2. Adding such complex features, does raise the low floor. Not in the way of features, but in the way of people's desire to program.
   Seeing complex stuff slows down people in wanting to learn something. Some people don't want to learn math because it's too complex. They feel like they will not succeed when they see older grades' text books. But when they reach it, if they understood, at least mildly, past concepts, they will grasp it easily, or at least they will grasp it.
   Also, there's a difference between math and Scratch. Math is completely obligatory, while in Scratch mostly only the basic features are obligatory, or not even in the educational program of school or even life, and that's why they keep going, and learning math, not because they want to, but because they have to.
   
3. How do you plan to implement this? Direct translation?
   

   class [example] :: cstart custom
     public :: cstart custom
       variable [var1]  :: custom
       list [list1] :: custom
     end
     private :: cstart custom
       variable [var2]  :: custom
       list [list2] :: custom
     end
     init (arg) ◄►  :: cstart custom // for some reason i can't use "constructor" in scratchblocks. I'll report it to blob
       set [var1] to [test] :: custom
       add [test] to [list2] :: custom
     end
     method [say aaaa] (arg) ◄► :: cstart custom
       say [aaaa]
     end
     property [type] :: cstart custom
       return [example] :: custom cap
     end
   end
   set [var v] to (new [example v] :: custom)
   set [prop v] to (property [type] of (var) :: custom)
   method [say aaaa] args: [] ◄► of (var) :: custom

   Or what? Because this seems to complex…
   

BurnedCrystal wrote:

Essentially you're saying the newcomers here are too unintelligent to understand something as simple as putting toys in a box based on their color

-Io- wrote:

Hello, duplicate

Man, i'm not going to read the whole discussion. But it feels like an attack against DaSpud.

I agree with DaSpudLord. This whole idea is too complex for a language like this, a block-based language directed to kids.

1. First of all, to people arguing against DaSpud, having programming knowledge doesn't give you the right to suggest concepts which not many people understand. You, Chibi (or should i call you Matoran?), even said that the current main community focus of Scratch is mostly not coding.
   It may have various projects where people do formally program, but most of them still not have as much programming as an ideal programming community, like most text-based programming communities, would have.
   
2. Adding such complex features, does raise the low floor. Not in the way of features, but in the way of people's desire to program.
   Seeing complex stuff slows down people in wanting to learn something. Some people don't want to learn math because it's too complex. They feel like they will not succeed when they see older grades' text books. But when they reach it, if they understood, at least mildly, past concepts, they will grasp it easily, or at least they will grasp it.
   Also, there's a difference between math and Scratch. Math is completely obligatory, while in Scratch mostly only the basic features are obligatory, or not even in the educational program of school or even life, and that's why they keep going, and learning math, not because they want to, but because they have to.
   
3. How do you plan to implement this? Direct translation?
   

   class [example] :: cstart custom
     public :: cstart custom
       variable [var1]  :: custom
       list [list1] :: custom
     end
     private :: cstart custom
       variable [var2]  :: custom
       list [list2] :: custom
     end
     init (arg) ◄►  :: cstart custom // for some reason i can't use "constructor" in scratchblocks. I'll report it to blob
       set [var1] to [test] :: custom
       add [test] to [list2] :: custom
     end
     method [say aaaa] (arg) ◄► :: cstart custom
       say [aaaa]
     end
     property [type] :: cstart custom
       return [example] :: custom cap
     end
   end
   set [var v] to (new [example v] :: custom)
   set [prop v] to (property [type] of (var) :: custom)
   method [say aaaa] args: [] ◄► of (var) :: custom

   Or what? Because this seems to complex…
   

This is an extended version of my reasoning for no supporting the original topic describing this feature, and preferring BookOwl's suggestion instead.

EDIT: Little edit. Forgot to reply someone.

BurnedCrystal wrote:

Essentially you're saying the newcomers here are too unintelligent to understand something as simple as putting toys in a box based on their color

Problem is, this is not sorting toys, but a much more complex concept

Chibi-Matoran wrote:

I said in my topic that I knew that other OOP suggestions existed already, but my way of implementation was different (mine uses variables and this uses clones). Honestly, I think my OP was more thorough than this one.

I think that OOP is an important concept to understand to succeed with today's popular languages.

too complex for a language like this, a block-based language directed to kids.

Chibi-Matoran wrote:

Let's coordinate the migration to Snap!. Everyone, abandon Scratch! Sadly, Snap! doesn't have a community website…

Chibi-Matoran wrote:

Let's coordinate the migration to Snap!. Everyone, abandon Scratch! Sadly, Snap! doesn't have a community website…

Jonathan50 wrote:

Chibi-Matoran wrote:

Let's coordinate the migration to Snap!. Everyone, abandon Scratch! Sadly, Snap! doesn't have a community website…

Scratch SHOULD take lambda and custom reporters from Snap!. Then literally everything that can be computed at all, and every possible data structure or WHATEVER can be made in Scratch. Honestly.

-Io- wrote:

First of all, to people arguing against DaSpud, having programming knowledge doesn't give you the right to suggest concepts which not many people understand. You, Chibi (or should i call you Matoran?), even said that the current main community focus of Scratch is mostly not coding.
It may have various projects where people do formally program, but most of them still not have as much programming as an ideal programming community, like most text-based programming communities, would have.

-Io- wrote:

Adding such complex features, does raise the low floor. Not in the way of features, but in the way of people's desire to program.
Seeing complex stuff slows down people in wanting to learn something. Some people don't want to learn math because it's too complex. They feel like they will not succeed when they see older grades' text books. But when they reach it, if they understood, at least mildly, past concepts, they will grasp it easily, or at least they will grasp it.
Also, there's a difference between math and Scratch. Math is completely obligatory, while in Scratch mostly only the basic features are obligatory, or not even in the educational program of school or even life, and that's why they keep going, and learning math, not because they want to, but because they have to.

-Io- wrote:

How do you plan to implement this? Direct translation?

class [example] :: cstart custom
  public :: cstart custom
    variable [var1]  :: custom
    list [list1] :: custom
  end
  private :: cstart custom
    variable [var2]  :: custom
    list [list2] :: custom
  end
  init (arg) ◄►  :: cstart custom // for some reason i can't use "constructor" in scratchblocks. I'll report it to blob
    set [var1] to [test] :: custom
    add [test] to [list2] :: custom
  end
  method [say aaaa] (arg) ◄► :: cstart custom
    say [aaaa]
  end
  property [type] :: cstart custom
    return [example] :: custom cap
  end
end
set [var v] to (new [example v] :: custom)
set [prop v] to (property [type] of (var) :: custom)
method [say aaaa] args: [] ◄► of (var) :: custom

Or what? Because this seems to complex…

define Myfunction (SomeArg)
DoSomething::grey

1. Classes
   
2. Objects
   
3. Scope
   
4. Abstraction
   
5. Inheritance
   
6. Polymorphism
   

• Scope. This is definitely related, but it doesn't quite fit. Why? It's already taken care of, more or less. You know when you define a variable, when you decide if it's for just the sprite, or global? Yeah, that's basically it. Just might need to add more options for more control, an easy thing to provide with a progressive disclosure model.
  
• Code reusability. Again, already kinda taken care of with functions and variables. This is important so that you can reduce the code you write, make it simpler to read (by abstracting details, showing you only what you need at any given time), and easier maintenance (by only defining things once, you don't need to change them multiple places). Of course, there's limitations to broadcasts (they're all global), which is the biggest thing preventing them from completely filling the role. There's also the issue of a lack of distinction for instanes, but I'll cover that.
  
• Abstraction. This is basically why we're implementing the whole thing, and is reliant on the user coding well. Maybe someone can come up with a way to present this concept in the UI, but I don't really think it's necessary.
  

1. Classes & Encapsulation
   The Concept: This is one of the most important and useful aspects. Simply put, this is just putting things into groups. This is where the “sorting toys” comes in. If they're related, you can put them together, and treat them as a group of things. This can improve readability a lot, as instead of keeping everything in one big group, you can keep them all nice and tidy. Quick to find things, easy to understand their purpose.
   The Solution: Unity-esque scripts/components. Now hold on before you complain that I'm using Unity as an example, I use it because IT WORKS. So the current set up of adding code/costumes/sounds to a sprite is cool. You make it, and add stuff, it's really simple. You can already have multiple costumes and sounds, so why not extend that to scripts? Make a list like those. Now that we've done that, we can extend the entire concept even farther by adding references. Instead of having a script/costume/sound directly defined in a sprite, you can create a sound/image/script and have it live in the “sprites” panel (which would then be called something like “assets”, “resources”, “materials”, “supplies”, or whatever). From there, you can just add it to the sprite like you would if you were adding a sprite from the Scratch library or your backpack, but it's in your own library and instead of completely copying everything, it would just be a reference (THIS IS THE CRITICAL PART, again a UI treatment needs to be made for this to work, this is what would make it work, whether it be some sort of link, visual designation, or whatever), which you could then open up separately from the sprite. This may sound complex, but I think that's mainly because I need to describe it in words. If you actually used it, and saw it visually, I think it would be rather intuitive (this would really just be a UI design problem, how it would be displayed, ina way that younger kids can somewhat relate to or at least grasp). If you really wanted, you could just have scripts defined as I described, and have a list of scripts you want to include, but I think that would wind up being more confusing. Could also use a block, but still seems ambiguous:
   

   AddScript[MyScript v]::grey

   
   TL;DR: Make everything modular, but instead of it being conceptual, actually have visible components (sprites, scripts, etc would all be treated somewhat as classes). That's kinda what Scratch does.
   
2. Objects
   The Concept: Basically clones. You create instances of your classes, the caveat being thatif it's a static function, you don't need to do so (something which JS and Python conviniently ignore, for better or for worse, so we can probably just use that same idea that you can either call the code ddirectly or from an instance). The class is the blueprint, and the obejcts are copies of the blueprints.
   The Solution: To be honest, this is one of the biggest things that confused me about Scratch: When you create a sprite, there is automatically an instance of it in the scene. I don't think it would be too far fetched, along with the asset-level idea explained prior, to just simply require a sprite to be dragged into the scene to have an instance of it. Drag it more than once, you have copies. Ideally, more instance-level control could also be added, so from your code you can directly reference a particular clone (ie to adjust its properties or call some method on it). Would also be nice to have some UI panel to adjust some default properties, but I can see this getting nasty and real complicated real quickly, turning into Unity's prefab system, which can get a bit complex, but there may be ways to handle it that would make sense (ie defining variables for the clone that have a default, can be overridden, and reset), but it may just add unneeded complication and a barely-used featureset. I'd need to see it implemented.
   
3. Inheritance
   The Concept: A class can add more functionality to a preexisting class.
   The Solution: I would imagine it would be best to have an approach similar to how I discussed classes. Use the similar reference idea, but basically the whole sprite/script would include such a reference, designated by soe symbol in the UI, a property in the sprite, etc. Similar to script references, any inherited assets would simply be a reference back to the original sprite (if that in turn is a reference, maybe there could be some sort of tree so you can go back to the source asset). Honestly not sure how many people would use this, it's possible that it's unnecessary, but I think this treatment could make it viable.
   
4. Polymorphism
   The Concept: A child class can implement its own version of functionality in its parent.
   The Solution: Basically just use the above, but have an option to “override” the original, so instead of just seeing a reference back to the original, it would be copied over, marked as an override (by some big red image or something), and you can manually adjust it (or maybe revert it). As above, honestly not sure how many people would use this, it's possible that it's unnecessary, but I think this treatment could make it viable.
   

LFP6 wrote:

That's because it is. That is obviously verbose and confusing in that it doesn't match with Scratch's block-based paradigm. What you're suggestig is just replicating programming but drag and drop.

Jonathan50 wrote:

LFP6 wrote:

That's because it is. That is obviously verbose and confusing in that it doesn't match with Scratch's block-based paradigm. What you're suggestig is just replicating programming but drag and drop.

Maybe you should say ‘replicating Java’, or ‘replicating C++/Smalltalk/whatever’, not ‘replicating programming’. Not all programming languages are like that, and Scratch is definitely programming already.

1. Feature complexity
   All of us, of course, should be focused in making suggestions/ideas easier. At the end of my post and on a later post, another Scratcher and I suggested two things that would make Scratch much more flexible, and have the ability of doing these (and much more!) complex things in an easy understandable way, but not directly.
   

   -Io- wrote:

   This is an extended version of my reasoning for no supporting the original topic describing this feature, and preferring BookOwl's suggestion instead.

   Jonathan50 wrote:

   Scratch SHOULD take lambda and custom reporters from Snap!. Then literally everything that can be computed at all, and every possible data structure or WHATEVER can be made in Scratch. Honestly.
   Google “church numerals” and “church pairs” if you don't believe me. And look at page 40 of the Snap! reference manual for OOP.

   Both concepts, easy to grasp. When I was starting to learn Scratch, I actually expected the list reporter to report the list I'm referencing to, instead of joining it with spaces.
   Then, ring blocks, which you basically insert a block inside them and then the ring actually reports the block and doesn't run it. With a run/call block you could make custom reporters, easier 1 sprite 1 script projects, etc.
   This is how it looks in the awesome Snap!
   
   So, you could do this:
   
   
   Looks complicated, i know, but if you look at it without just saying “Agh! A bunch of blocks that don't make sense!” you can get the sense of it easily.
   That's basically:
   

   define all but last of (list)
   repeat ((length of (list))-(1))
     change [i v] by (1)
     add (item (i) of (list)) to (result::list)
   end
   return (result::list) ::cap custom
   
   (all but last of [list v] ::custom) // assuming "list" is the list [a,b,c,d], it returns [a,b,c]

   Of course, we shouldn't just keep the ring blocks and not add custom reporters. Custom reporters would be much more comfortable.
   
   
2. Complex projects already exist
   Sadly, this is a problem for every programming language you'll see
   There isn't really a clean way of making big projects without ending up in a mess that someone wouldn't get the first time they see it.
   The cleanest way I see of implementing OOP to Scratch (remember, not directly! Those features are for other things too!) would be by the suggestions referenced above.
   
   Also, you don't see the complexity while creating with what we have now. By adding a bunch of blocks like class, property, method, etc.; or making it so dropping sprites in the stage creates instances, just overcomplicates stuff for a language as simple as Scratch, and when a young kid sees the whole lot of stuff you need to do to make things works just slows them down. That gives us a small chance of them continuing to program and learn, because they don't know anything.
   
   
3. Unity-esque features
   Oh man, this would change every aspect of Scratch :S
   Personally, I feel like implementing stuff like this is somewhat dirty, unorganized, and confusing. Although I do understand everything about this, making it into a UI just deorganizes stuff.
   
   I don't have any grudge against this other than it changing a lot of Scratch and it being confusing and unorganized when turned into an UI. I feel like young me, as a dumb kid starting to program, wouldn't get anything a would have just dropped out programming.
   

Random person wrote:

How do you use pen?

Random person wrote:

I just looked at the last subject in my Math book. I'm not going to pass school D;

-Io- wrote:

Remember there's no need for this to be in Scratch. There's no need to teach everything on Scratch, just like there's no need to teach everything at school, and that you later learn the complex stuff in the university. You learn the basics – maybe some complex stuff – with Scratch, and then move on to text-based programming for the real deal.

zekrom809 wrote:

the anti-OOP people

-Io- wrote:

zekrom809 wrote:

the anti-OOP people

Excuse me, what?

liam48D wrote:

-Io- wrote:

zekrom809 wrote:

the anti-OOP people

Excuse me, what?

*googles “OOP is bad”*
*finds this, this, this, etc*

zekrom809 wrote:

Okay, maybe I didn't put that the right way.
Rather than “anti-OOP”, say “people who don't like this idea”.