The thing is, half of your object representations are things that weren't invented specifically for objects, but just come free with first class procedures and lists. So I don't think it's fair to blame us for there being so many ways to do it; that's true in most programming languages these days, since they all (except Python) have lambda.
Also, as the manual points out, sprite inheritance is an idea that's in Scratch, but done right, so it really inherits instead of making a copy. And it's nice that using local state variables with lambda can implement OOP because we always want people to be able to look inside an abstraction, and that's not really the case with sprite inheritance.
The reason for OOP 2.0 is that Jens reports that German high school CS teachers couldn't figure out how to teach with the sprite version; they keep looking for buzz words (such as "method" and "class") and I guess can't be bothered to read the manual. (Sorry if you're reading this and you're a German CS teacher and you feel misrepresented!) So now we have a way to do OOP that looks just like Python. :~/
that was just the first example that came to my head, and no, scope inheritance in snap isn't like other languages. being able to list the variables local to any ring and assign those variables to other rings doesn't have an equivalent in any other language i know of, and the whole thing relies on it. you can't just get every variable that's inside a javascript function.
this stands out to me a lot. i've seen jens get annoyed about kids being clever on the forums, and wants more creative projects, but i don't feel like that could happen with how it's currently going.
snap to me feels like every classroom's worth of lesson plans mashed into one. like any lesson plan, even "creative" school projects never actually have room for creativity. the rules and grading scheme always get in the way. in the case of snap, all the bugs are rules, and trying to use the languishing features feel like extra work for a worse grade.
the ui and features feel to me complex in a way where it only makes sense if you've already been told what to do (continuations, block creation, etc).
i can often see sets of features that are clearly designed to go together, separate from other features, probably part of a specific lesson plan. usually if you put together unrelated things, snap breaks in one way or another. i stopped writing the post for a couple minutes just to look for another one, this freezes the page (ignore the sprite name, i just threw this together in a tab i already had open).
many snap features i don't see how they could work. RUN WITH CONTINUATION made sense to me, the continuation is everything below the block, but since it got replace with the reporter THIS CONTINUATION, what even is the continuation? you still need to continue running the outer code to do anything with it, and even expressions can have side effects in snap.
all the more powerful pen blocks like pasting and pen trails would be incredible for complex drawing in games (perhaps turn textures into vertical strips for a doom engine?), but in practice they're often much too slow to use well. scratch can fill the screen with thousands of stamps per frame just fine, and it gets used plenty, but snap struggles well under 100.
all of it very much looks designed for basic lesson plans and nothing serious. on it's face that goal is fine, but it really seems like the goal is more than that, and even if it really is just for basic lesson plans, wouldn't it be better to divide snap up into the lesson plans, and other features to help teaching?
i really do still want to know what the actual goals of snap are. the ways features are talked about and prioritized just don't make sense to me at all. there are so many incredible new ideas in here and i really want to see them get used for way more than what they currently are, especially the weird ones like scopes as data and scope inheritance. everything in lesson plans have already been done to death.
That's been a thing for a while, because it's a teaching language and a lot of teachers are used to teaching text languages and a lot of assumptions are made, I think in order to account for imperial design and functional design, and the things that teachers are looking for and not finding because of language differences and just assuming snap doesn't have it for whatever reason.
I think I found the method variables by accident the one time I clicked "For This Sprite Only" instead of "For All Sprites"
This also why I wish they'd continued the SAP Snap courses, because the first two have some pretty cool explanations in them, but aside from explaining big ideas, really didn't have any concrete purpose.
A Third Snap SAP course that maybe created a concrete program of some description would have been awesome. Wether it was a paint program or a game, something that said, try creating this, and as a conclusion, "You've made your first app, now make a different app that does a different thing"
The problem is, there is no concrete course for it, there's no follow ups, and well, there's a reason a lot of people try not to use the term computer science anymore, because it's not really a science, there's no baseline, there is plenty of arguing though. Plenty of it, usually covering the same ground over and over and over again.
The only real next step appears to be "use my flavour of obfuscation" and they are all, quite frankly garbage.
I'm not understanding what you're describing here. Could you give an example? Thanks. (I mean, the code in the OOP-through-lambda chapter in the manual is taken almost verbatim from SICP.)
Yeah, I take your point. One thing we're talking about doing but haven't gotten around to is to have "drawers" in some palettes, so sub-categories of primitives can be hidden-but-discoverable. So you'd see, for example, "Scenes ︎" and when you click the arrowhead it points downward and the scene-related blocks appear. I think the "hidden but discoverable" idea is important -- both parts are important. This is especially a good idea for Control, but could be useful for Lists and Operators also.
... but I don't think this is fair. You can't expect continuations to be understandable without help, no matter what the UI.
As for make-a-block, here the issue isn't the inherent difficulty of the idea, but rather the myriad details the user has to specify. We could present the user with a sequence of smaller dialog boxes, one headed "what category (color) do you want your block in?" and so on. (In fact, now that you have me thinking about it, I have a vague memory that that was my very first proposal for the UI.) That would arguably better the first one or two times you make a block, but we rejected it because it would be annoyingly tedious from the third time on to forever.
Thanks for the bug report! Yes, I understand that you're making a more general point, but the bug report is helpful too.
I share your preference for the traditional continuation blocks. Luckily, they still exist, in a library, which is unfortunately two screenfuls down in the list of libraries. (I think it may be time to abandon my effort to put the libraries in groups, and just list them alphabetically -- although Jens will rightly point out that that's not translatable. Or maybe we need drawers in that menu too.)
Pen trails is slow? It shouldn't be; we should have the bitmap already available as a costume, since they're in a separate layer. I can see why pasting onto a sprite might be slow, but it's not fair comparing our speed with Scratch about that.
Nobody asks text languages what their goals are. It's understood that it's the users of a programming language who have goals, and the job of the language is to support all of them.
In the case of Snap!, I think it's straightforward to understand that we have two fairly disjoint sets of users, one composed of teachers and students in their roles as such, and the other composed of independent learners/programmers. Your proposal to divide Snap! into a bunch of separate learning environments would prevent supporting independent users. But the newish "microworld" features should allow us to do what you're suggesting on a temporary basis. It's hard and time-consuming to invent good ones, but this is an area in which teachers could help us.
the blue [variables v] of (ring) block isn't in any other language.
i don't expect continuations or the block ui to be easy to use, my issue is that things aren't really discoverable. i don't think just being able to see a block is enough, and i don't think hiding features behind a menu makes everything else much simpler.
no menus. every operation is just dumped onto the screen and numbered.
i of course wouldn't consider this an ideal ui, but for the situation, it's a lot better than it looks at first.
i don't take issue with complex things being complex, my issues are when i really do think they could be made easier, and it's almost never about hiding or showing things, but reframing them and organizing them.
hiding complex blocks makes them annoying to access and might make it appear as though features don't exist. people using most programs wouldn't look through any of the top menus. why is adding scenes there when it could be a button next to the stage? why are libraries in the top menu when they could go next to block categories?
it's difficult to try and use any block library.
the description doesn't really tell me anything. i can't see inside these blocks or try them out until i import them into my project, and if i do, they might be nearly impossible to remove, because i can't see how many hidden blocks there are. some libraries have hundreds of blocks.
from just the titles, can you tell me the difference between "declare and initialize script variables" and "create variables"? the whole page will freeze for a good few seconds if i click over to look at it.
what does clicking the arrow do?
enough drawers and menus and dialogues! i get that they're easy to throw in but it's just too much! when's the last time you've looked at scratch? better yet, look at turbowarp, it's been plenty extended.
in the block categories, the extensions are unmissable, and every extension always gets its own category. unused extensions automatically disappear when you reload the project (not the best, it would be better if you could remove them explicitly, but it's a big step up).
beautiful extensions menu. i wouldn't call this list of extensions particularly high quality, many are duplicates and it's still sometimes unclear what they do, but for user made extensions it's certainly not bad and the immediately visible images are excellent. if you've used an extension before, you'll always be able to find it again.
i think it's nice to see that the sprite management is over here in the sprite pane. if a small element changes far away, the user didn't see it.
i'm still not really sure what that's doing up there. and snap has all these other tiny missable buttons:
scratch and turbowarp feel like title text in comparison
all my forum posts feel too long so i'm going to quickly wrap this up
i swear someday i'll help redo abi for all the systems languages, but it sure doesn't feel possible. i'd have to at least start by writing a compiler and i haven't done very well at that.
snap is comparatively low hanging fruit. i can talk to people here easily, it's a webpage with reasonably simple code, i have the firefox flame graph, the javascript interpreter lets me look at whatever i want when i need, many of the hidden or complex features get explained in the forums, and the explanations really do make it feel simple. snap is the very rare case of a language clearly with goals yet to be achieved and without incredible complexity in maintenance.
not really a proposal, i'd absolutely hate it. it's just something i would expect if snap's supposed to only be a learning tool.
scratch does the teaching/independent learning split quite well. from my understanding snap is trying to do that while introducing more complex concepts, so that teaching can be done at a higher level, and independent programmers have more flexibility. but i often see important things for independent programming treated as low priority and i wonder if i don't have it right.
Oh, okay, but that's not something we need for OOP-through-lambda, because it's not in Scheme either. The (only) great thing about lexical scope is that class and instance variables Just Work.
Oh, that's a beautiful example of GUI gone mad! I was just explaining to a (non-Snap!-related) friend why I'm a Mac user rather than a Windows user, namely, on the one hand I like being able to stick in a DVD and have it Just Work, but on the other hand I can't live without a Unix shell window. "How do Windows users do rm *.o, I asked plaintively. Now I know the answer. But I like that it has a roman numeral option!
I think it would help if some of those option sub-boxes were in a slightly larger font than others, or maybe boldface. But also, that has to be intimidating to beginners, and a UI that hides some of the options behind an "advanced" button wouldn't hurt.
Yeah, okay, you can make a case that beyond a certain number of features, nothing is discoverable. That's something Scratch got right in their early days. It's why Jens is so reluctant to add blocks, although I'm not convinced that hiding them all in the LENGTH block is an improvement.
Although discoverability is important, I would argue that it's not important for everything. If the only way to learn about continuations, even that they exist at all, is to read the manual, I can live with that.
Make-a-block is a different case, of course. The issue isn't precisely discoverability; I think everyone realizes that you can make blocks. The issue is that we should build in a tutorial. Maybe the dialog should have a Help button, which maybe should walk the user through a sequence of simple dialogs that ask questions.
But I'm not sure that's necessary. We don't often observe students having trouble with the mechanics of making a block. They do have trouble, sometimes, with the one Big Idea hidden in custom blocks, namely, the difference between formal parameters and actual arguments. But that's what the manual and your teacher are for.
It's definitely become harder since we passed the point where they all fit in the window at once. Some of the descriptions are better than others, and it's not fair using continuations as the example of a description. How would you describe it?
I wish I could pull a block out of the library dialog into the palette (and also get the blocks that that one needs as helpers, hidden). That would help with cases such as SciSnap!. At the other extreme, there are too many libraries with just one block. That's too ponderous a mechanism to get that one block.
Nope, I can't, good point. Those should be one library. Basically it's two libraries because Jens approves of one but not the other, I think.
Oh, c'mon, that is discoverable! Go ahead and click it and see what happens.
Every extension getting its own category is the right thing for big extensions that implement a microworld (in the true sense, something that extends the language, not something that hides features). It's not so good for one-block or two-block refinements to an existing category. When we talk about this question, we distinguish between libraries and extensions, although that distinction gets mixed up with the more technical meaning of "extension" as something written in Javascript. Arguably we should have different interfaces for big and small libraries.
This:
is indeed beautiful for large extensions, but way too much screen space for tiny libraries. It's bad enough that our library list is three screenfuls; it'd be unbearable for users to have to flip through ten of those fancy pictures.
And, in fairness to us, in that picture I have no idea how Skins differ from costumes, or what Sensing Plus senses, or what kind of events More Events adds, ditto List Tools. You're analyzing our faults much more deeply than theirs. All of those paragraphs need examples.
Thank you, I guess...
We just all have slightly different ideas about what independent programmers need. I think metaprogramming is a huge win, although on the very long list of things I'm not getting around to doing, I think I could improve the UI, mainly by introducing the concept of a macro.
SIZE is a formal parameter; 100 is an actual argument. If it said SQUARE (50 + 50) then "50 + 50" would be the actual argument expression and 100 would be the actual argument value.
not neccicarily, i think ideally some existing libraries could do with a bit of rearranging. i don't think single block categories are too much of an issue though. scratch has buttons to scroll to a category, but not all the categories are shown at once. if you could scroll through categories instead of paging through them, lots and lots of categories wouldn't be an issue. i would certainly prefer it to categories with lots of blocks from many different places.
I dunno. I like having all the blocks about lists in one place. If you invent, say, blocks about circular lists, I'd want them there. (Some would in fact replace primitives -- all the higher order functions, for example, would have to detect circular lists.)
i haven't programmed in scheme, maybe i should learn its concepts.
i can't click it! it's in the "add library" ui, before adding it. sure i could add it, but as the libraries get larger, if i find it isn't what i want it'll become harder to remove. it would be a lot nicer if i could interact with individual blocks there, maybe even drag them out and start using them immediately.
i did mainly want to highlight the good in that ui, because my point is looking at it to see what you can take away from it. it's absolutely too big, even for turbowarp, and all the images would work at a much smaller size. even just giving every extension a color i think could help, because i'll remember the colors after the first time.
i don't particularly like scratch anymore, and i don't care for turbowarp either. all i do on scratch is look back at my notifications maybe once a month. it has no variable scoping, sprites are inflexible, i can't see what blocks are in extensions (i don't like that i can't interact with the blocks in snap, but seeing them really is a massive step up and i'm glad the ui has it)
i think the one thing that stands out to me about snap is it seems to be considered pretty much done. it seems to get features added less often than even c. as for turbowarp, i think i did look into making an extension for proper script variables? there's a few that claim to do it, but they don't. i don't actually remember how far i got with that, i think i got stuck somewhere and forgot about the project.
i second this, metaprogramming is a huge win. most the time when i find i can't do something i want in any language, it's because the metaprogramming isn't good enough. good name too, most other types of metaprogramming are more specific or not quite what snap does, and this name really covers the intent.
i would much rather have a category specifically for circular lists. libraries often come with quite a lot of blocks (or you need a bunch of libraries that add up to a lot of blocks), and they're usually for a purpose more specific than the existing categories.
as for replacing primitives, i'm pretty sure if two libraries replaced the same primitive, one would be lost and the library would stop working. for making common operations work on new types, i generally think of the rust feature "traits", usually in other languages called "interfaces". instead of having one bit of code that does an operation for every type of data, every type of data has a bit of code that does the operation. for example, Iterator is a trait, and the map operation is a part of the trait, so you can map any iterator, and you can make your own iterators that can be mapped. traits get used for all sorts of operations like math and indexing lists.
i'm not really sure how that could be done in snap. none of the list primitives can check for dictionaries to do duck typing, and even if they could it doesn't feel like a neat solution.
You worry about that too much. Let me introduce you to the "Unused blocks" option in the File menu. It finds all the blocks you have in your project but aren't actually using, and lets you delete them all at once.
Oh yeah I should do that, thanks for reminding me!
I can't speak for C, but Jens has the next three or four major versions planned out. We typically have one major release a year, in time for Snap!Con. And plenty of minor releases between times.
augh typo, i meant SCRATCH seems pretty much done. snap doesn't seem done at all, it gets massive updates regularly!
not really. if two different objects have the same named method in java, that doesn't make them interchangable. if you're thinking of inheritance, objects that inherit come with data, so you can't inherit multiple different objects. even with interfaces, that doesn't necessarily mean you have an interface for many language features. javascript doesn't have operator overloading, so you can't make custom number types that use the operators. rust has many operators that don't have usable traits yet, like Try
Neither Java nor Javascript is object oriented. (The only object oriented language is Smalltalk.) I say this because if you're thinking about those languages, you have a limited feel for the variety of OOP ideas. For example, objects totally can inherit from multiple parents! We had multiple inheritance in Object Logo. In Smalltalk, numbers are objects, with their own methods and so on. So the question of "overloading" doesn't arise; the + symbol names different methods in different classes, like any other method name. If for some reason you think it's a good idea for it to mean concatenation when applied to strings, you can make a + method for strings.
But my point is,
is precisely the definition of OOP. Methods are grouped within an object, rather than grouped within a generic function.
︎" and when you click the arrowhead it points downward and the scene-related blocks appear. I think the "hidden but discoverable" idea is important -- both parts are important. This is especially a good idea for Control, but could be useful for Lists and Operators also.
