Thank you so much for explaining! This is exactly what I needed!
May I ask why you are opposed to discussions about metaprogramming? For me, it’s useful to create custom background systems to be used in actual creative projects. I’m not just interested in it for the sake of it.
naw it's okay, I guess. I'm somewhat irrationally irritated that we're creating a colorful programming language for beginners in introductory programming classes, and rather than fostering liberal artsy discussions it's turning our community into the nerdiest, techiest place I know. Sorry!
Well, that really proves that Snap! is a great tool for learning computer science concepts!
For me, I really think that's the point. Snap! first and foremost is a code platform where you can see what's inside the box, and if you like a program, the first instinct is going to be "how did they DO THAT" and then seeing how they did it and going "oh that's cool" or "Hrmm, could that be better?" or a mix of both.
Like that RPG game with all the art generated via rings, that's cooool. Something to truly show off the power of snap.
For me, there's only so much that can be taught, the rest is exploration, and snap! is very much designed like that, it's perfect to learn on and to explore on, which, in my opinion matches the idea of "Low floor, No Ceiling, Wide Walls"
If you want a liberal artsy community, we have to work harder at fostering one. For example, we dropped the ball on Topic of the Month. We don't have commenting on projects yet. That never quite gets to be the highest priority, not even the highest community-site priority, for good reasons, but still... Maybe we should rope in people like @loucheman to do this community-building work.
It can't be me, because I'm not that kind of person.
I think that I shall never see
a poem lovely as user-visible continuations.
:~)
i'm entirely with bh on this. i don't see how artistic projects could reasonably keep up and i'm genuinely confused every time you say you want it.
i spent a month working on a project recently and i'm not sure anyone even noticed? i'm pretty sure you only bothered to look at my adofai project you featured because i posted it in the middle of an argument. you haven't featured any of the much more interactive and complete projects i've seen since then, like the impossible platformer 2. all of the projects i see on your profile are tiny and not particularly interactive. i'm not sure if your profile even shows all of your projects? it only lists 20.
pretty much every snap update is new features with only technical explanations. the manual is too massive and out of date to use. new changes happen so often that it's incredibly difficult to keep track of how features actually interact. projects end up corrupted regularly. the costume editor is too lacking in features to actually use. there's no sound editor at all. scrolling through blocks is incredibly laggy.
even if all you want to do is add new blocks with new features, there's plenty you can do that would be way simpler and more useful. i'd get massive use out of some more sprite effects and pen operations. something for multiply and additive blend modes would let me do a lot more with the pbr lighting project i have sitting around.
I'm not entirely sure I understand how the rest of this message follows, so I'm not sure you're "with" me...
Colors and crayons library! :~)
Here's a tip, if you are going to suggest something to be added to snap, you have to explain why you can't already write it in snap (or why it's impractical). This isn't really aimed at you, it's just something I wanted to get out for anyone wanting to suggest something to be added to snap.
For this example, why can't you just write the blend modes yourself? It's just image processing after all.
Now yes, I do understand what you mean, blend modes to be used for overlapping sprites. It's not practical to run an expensive calculation on sprite costumes, and also be able to figure out where sprites overlap, so you can only modify the overlapping pixels.
This is actually why the cut [ V] block was added. Someone was trying to create it in snap, and with many people helping, they did mostly manage, however it was slow, and didn't give the best results (especially on the edges of costumes with the transparent anti-aliased pixels). Jens then decided to add a primitive to speed it up, and give much better results (because it just uses the javascript canvas api instead of dealing with every pixel manually). Not to mention, it actually also now allows you to do some cool effects with it.
Now yes, the example with the cut [ V] block didn't stem from a feature request, in fact, I'm pretty sure jens added it himself without any request. However, I feel like this does still give you an example of what kind of stuff that might get added to snap from a feature request. There has to actually be motivation as to how it can be useful, and why you can't already create it in snap.
I’m with @sarpnt on this. May I suggest a moratorium on new Snap! features? Better get user-level documentation and stability up to par first.
Sigh. Documentation is my fault; Jens stopping working isn't going to help with that.
I've been telling Jens not to take complaints as attacks, but now I'm caught up on this thread I can sort of see how he gets that way. The language of "I'm with X" isn't helping; it does make this sound like a dogpile rather than the useful discussion I'm sure you intend.
Re-reading this particular post (in its entirety, not just this first paragraph), I'm afraid I can sorta see why Jens feels attacked.
This has nothing to do with what features we do or don't add. You're feeling neglected, and that really isn't relevant to the technical discussion. When you add
even I can't read that as anything but a personal attack on Jens. It's not his job to make projects! Even though he does make some great ones.
If this is true, we definitely need to know about it, but it's unhelpful to say it in the abstract without examples. I know of one example of projects being corrupted by recent updates, namely, when someone loads the Embroidery library into a project that doesn't need it, because it overwrites primitives. This isn't a bug; the library is behaving as intended. But more than one person has been caught by this behavior, and I think it's reasonable for users to expect that they can explore the libraries without getting in trouble. We should, I agree, give users a warning if they load a library that modifies primitives. Maybe, also, like the bignums library, the embroidery one should come with an on/off switch that defaults to off. We're talking about this question. But if you know of another example, please be specific!
This is true, as is should be, only of updates that change the first or second number in their names. Jens also releases a constant stream of releases increasing the third number, subminor releases I guess they're called, that are entirely bugfixes and translation updates.
This is a legitimate complaint, but it's not helpful to include it in a (sorry) rant directed at Jens. As I write this, I also realize that it's not the users' job to understand the process among the Snap! team, but nevertheless it'd be helpful if you could understand that Jens is even more upset about the state of the manual than you are.
Also, I point out in my defense that the "too massive" part of this complaint is incompatible with the rest of it. You want complete documentation of obscure features, without the manual getting bigger! And by the standard of other languages, our manual is tiny. Go read the Common Lisp manual! It's full of things like detailed explanations of the mathematical behavior of trig functions of complex numbers.
Yes. We're well aware of this, but it's a valid complaint. You could make a good case that that's more important than input groups. But this gets lost in all the other things you say here.
Things that can be written in Snap! itself are good candidates for user-written libraries.