Suggestions from the Citilab Programming Clubs

Request a new command, feature, or improvement

Moderator: MSandro

Post Reply
bromagosa
Posts: 33
Joined: Sep 15th, '15, 07:11

Suggestions from the Citilab Programming Clubs

Post by bromagosa » Nov 12th, '15, 10:23

Hi!

I'm copy-pasting a couple suggestions from our programming clubs, in no particular order:
  • People avoid building custom blocks because the "define" stack takes up space and that bothers them, plus the block prefix (my class_foo) and the default "this" upvar scare them.
  • The "Class" nomenclature is a bit confusing, for a couple reasons:
    • Seasoned "OO" programmers (albeit seasoned in not-so-OO languages) expect the first object of a class to be a class definition, they then expect changes in what they think are instances of that class to not propagate "upwards", and get confused when that doesn't happen.
    • Beginners don't know what classes are, so they don't benefit from the nomenclature either. They do understand what clones are though, as they've seen them in Scratch and Snap!, and although instances in GP don't map exactly to clones, I feel they're closer to Scratch clones than to traditional instances of a class. Maybe just renaming "Class" to "Object" and "Instances" to "Clones" would help both groups grasp the concept better.
  • Both beginners and somewhat experienced programmers have a hard time understanding why "animate" works different than "while true". I had to explain this a million times to them, and they still repeat the same mistakes over and over again. I'm not sure what the right abstraction should work like. Maybe the "animate" block should be reworked into a "forever" block that only waits for the next rendering frame when there are graphic-related blocks embedded in it.
  • Users miss a way of combining projects. In our programming clubs sessions we encourage people to split into smaller groups and focus in different parts of the big problem, but then I have to manually join their pieces together in a text editor, and they feel I'm performing some kind of magic they can't control.
Overall, they all like GP and are very proud of being part of the alpha testing community! :)

JohnM
Posts: 379
Joined: Sep 11th, '15, 14:42

Re: Suggestions from the Citilab Programming Clubs

Post by JohnM » Nov 14th, '15, 19:21

Thanks for this feedback; it is very helpful and thought-provoking.

Clones in Scratch are actually quite similare to GP instances. In Scratch, changes to the scripts in the original sprite are now propagated immediately to all its clones, but Scratch did not always work that way. Originally, each clone got a snapshot of the sprite's scripts when the clone was created and after that the clone was independent of the sprite from which it was cloned; changing the scripts in the original sprite had no effect on clones that had already been created. However, this caused confusion. When people changed a script in the original sprite while their project was running, they expected all the clones to feel the change immediately, as if the original sprite were a class.

GP differs from Scratch in treating all the instances as equivalent. You can view any instance, and editing the scripts in that instance immediately applies to all the other instances. In Scratch, the original sprite is a special instance (which some people might call a "prototype" or "exemplar"), and that's the only instance you can view and edit. That special instance also has a name and shows up in the sprite library, whereas it's clones are anonymous and don't show up.

The Scratch clone model does seem to be fairly easy for users to understand, and it provides a nice evolutionary path from a finite set of named, manually created concrete instances to a variable number of anonymous, dynamically-created instances. From what you say, it sounds as though both seasons "OO" programmers and beginners might find a more Scratch-like model easier to understand, and I think that changing just a few details of the GP programming environment would make it feel more Scratch-like.

Re: animate vs. other loops

We've renamed "animate" to "forever" in the next version of GP. As in Scratch,
that will be the starting point for animations and interaction loops, and it will
have a built-in "wait".

We are considering the idea of adding an optional boolean parameter to the other
loops named "animate" which, if true, would add a wait to the end of the loop.
Do you think that would help?

Re: Users miss a way of combining projects

Yes, I miss it, too. We'll try to figure out some way to import scripts or projects.

You've given us a lot to think about.

-- John

bromagosa
Posts: 33
Joined: Sep 15th, '15, 07:11

Re: Suggestions from the Citilab Programming Clubs

Post by bromagosa » Nov 16th, '15, 08:49

Hi John,

About OO

My critique was not to GP's OO approach, which I think is perfect! I was just talking about names.

In my opinion, just renaming classes and instances would be way enough to clear these confusions. Classes could be named Objects, and Instances could be named Clones, for instance (pun intended, couldn't resist).

About forever

The change to forever is just what I was thinking of. Would it be possible to have it perform as fast as possible when looping over non-graphical blocks?

All objects in GP have a default graphical representation upon creation, so I think it may make sense to have animations be the default behavior for all kinds of loops. Maybe the default thing should be for all loops to wait, and then a variadic input could be used to make them run "turbo".

Re: combination

I read your paper on GP modules. Couldn't you maybe reuse the module abstraction for this?

Looking forward to 0.43!

Post Reply