I also disagree with this behavior. Just read this whole thread. At least the issue that I originally made the topic about was fixed (there was no error message).
manipulating blocks to grab sprite local variables doesn't make sense, you can have multiple variables with the same name.
if a sprite has a local variable with the same name as a global, that sprite will only be able to access the local variable unless it uses the OF block or a ring. same with any script local variables.
the sprite that runs a ring isn't the environment. if you create a ring in one sprite with MOVE 10 STEPS, and then run it in a different sprite, the sprite that created the ring will move, not the one that ran it.
this isn't your fault in this case though, because there's two actual confusing issues in your thread. MY BLOCKS definitely should return rings with the environment of the sprite you're getting the blocks from, because that's where the blocks were created. it should work like creating a ring in that sprite.
jens is also just being extremely rude and throwing around way too much jargon. i have no idea what jens is even saying here other than the insults.
In Snap! we have the same representation - a ring - for both a function and a quoted expression, because they are very similar. Expressions are quoted so we can get a handle on them to take them apart and assemble them into new ones, programmatically generating scripts and custom blocks. For this purpose they don't need to capture any environment, and in most cases capturing environments would be awkward and lead to surprising results down the road. Therefore functions capture their environment, quoted expressions don't. Quoted expressions are thus "unbound functions", just a wrapper around code. If the code doesn't rely on side effects - e.g. it merely consists of mathematical operators - you can directly call a quoted expression, otherwise you must bind it to an environment using the OF reporter.
In the OF reporter's dropdown you can find another sprite's methods (local custom blocks), and you can directly call them as they will be bound to "their" original sprite.
the MY BLOCKS reporter answers a list of quoted expression, i.e. unbound functions. You need to bind them first to a target environment if they rely on side effects or local data. You can use the OF block that. The OF is hyperized, so you don't have to enumerate the list of blocks.
If you "make a ring" using JOIN as this thread is titled, the same applies. JOIN produces just code. You can directly run that code, unless it relies on external bindings, global or not.
I really don't like being called by the same folks about the same things over and over, especially since I believe that discussions like this one scare away the target audience I want to cater to: Teachers and students using Snap in class. Instead this forum seems to be perpetually dominated by a few overly enthusiastic nerds knocking themselves out about esoteric fringe topics, constantly calling out for attention from us devs. Folks, you gotta realize that I'm answering dozens of emails and DMs about Snap! all the time. And I'm always sad that those questions aren't asked here in this very forum, because I believe that (many!) others would benefit from those conversations, and because that's what a forum is made for. But there's a reason other people shun this place, and it makes me unhappy.
joining rings is the only way you can create code without an environment, and most people don't pass rings between different sprites or try to change environments without the syntactic sugar of the TELL and ASK blocks. of course people are going to be confused by it on a regular basis. there's no need to be rude to people about it when they think it's a bug. all those bounds checks you aren't adding might not be important for experienced people, but it gives the impression that snap has a lot of bugs, and people will follow patterns.
the forum allows people to talk to other people, and the way this particular forum is designed makes it really easy to read up on posts and remember people. of course there's going to be a lot of people that post all the time and talk to eachother, it's a community and there's nowhere else on snap to do it. these are the same nerds that show off interesting projects, that collaborate to try and make better projects, that help eachother with issues, etc. teachers and students are busy learning the basics, you're far less likely to get the kinds of interesting projects you've told me you wanted before from them, and they might not even be sharing anything.
note that this doesn't mean all these people have telepathy or read every post, different people are going to run into the same issues, and that's common for anything confusing. how is codification a fringe topic anyways? from what i know it's the main big feature of snap 8 (or maybe it was a different update, i don't remember). the reason d4s is making a text language is because of a post bh made reccomending to make a scheme interpreter.
i have plenty of suggestions, bug reports, and project ideas for snap that i'm not acting on because i get the feeling that you'll get annoyed and ignore it.
There are a lot of us doing that - not acting on our ideas
Or we mention them once and then hope they might be implemented at some time in the future 
We don't keep telling the main project lead that they are not getting things right
The reason for that is that this isn't our project
No-one jumps in on the Python team or Guido van Rossum with lots of suggestions
There is a Snap! team who discuss and talk about the direction of Snap! and then mainly Jens goes off and does it.
There are always many things that many people think should be enhanced/changed/fixed
There is only a finite time in which to do this in
You will most likely look back over time and come to see that this is the way with 99% of all programming languages / software projects
IMHO, from a retired educators point of view, all the macro/script stuff is very advanced and intended for a select audience.
I know it is very hard, but try and take a more relaxed approach to things here, think about the big picture
pleas don't assume that by "act on" i mean repeatedly ask for the same thing until it happens or i get banned. i respect people's time. if python had an actual bug i wouldn't be avoiding reporting it because i expect some staff member to complain and tell me the bug isn't worth fixing or that it's some fringe idea.
by "act on" i mean mentioning and discussing ONCE, and/or submitting a pull request. i've had jens get annoyed before because i ran into quite a few bugs trying to make a project, and reported them when i saw them. jens then went on a rant about how people aren't making cool projects and just shoving random garbage into blocks.
The only reason Python has even its stunted half-implementation of lambda is that his users insisted.
I don't think it was wrong to raise the question. It happens to be a question Jens and I have discussed, but we didn't have the discussion on the forum, so there's no way you would have known that.
About Jens yelling at you, he shouldn't have done that, especially because you're not the one he's annoyed by. The problem of people being scared away from the forum is a real one, but it's not, imho, anyone's fault. On the contrary, as you say, it's great that we have users who have the experience and the interest to pursue science here. Jens is unhappy because we seem to have only those users, even though he runs workshops for Snap!-beginner kids who get to make interesting, meaty, not-so-much-about-CS projects. I'm unhappy about it, too. That's why we started Topic of the Month, to encourage people to publish projects that aren't about lambda calculus (or, as in this thread, about typed lambda calculus).
Yes, exactly. We have to triage bug reports into categories
- User error/misunderstanding.
- Bugs, but too trivial to worry about.
- Bugs that are fixable and worth fixing.
- Bugs that would take a big redesign of the code to fix.
- Design disagreements.
I think it's only that last category that annoy Jens, although IANJ, YMMV. I, on the other hand, am happy to argue about the design, although it's rare for such discussions actually lead to us changing anything.
I am not Jens,You ___ __ __?
yeah nice
But its unlikely for a user to maark stuff as misunderstanding
i've been sitting on this for a while, because i know it'll really annoy jens, but the main reason i haven't released any projects that aren't lambda nonsense is that snap is just WAY too slow to make games in. i have a game i made in scratch that has horribly tangled code, with bugs i can't be bothered to try and fix, and would benefit from things like creating costumes with code. i tried to port it over, but snap struggles from a tiny fraction of the stamping that scratch can handle.
yes, i could probably optimize it, but it would take a while and there are many other things i would rather be doing. i also get the feeling that i would run into more performance issues later, or with other projects.
something that really bugs me about performance is that to stretch or warp costumes in many common ways, it requires creating a new costume, where even the single blocks are often slow. how am i supposed to optimize one block? i might want to stretch and skew 20 sprites every frame.
i think there's other cases of single blocks being unusably slow, but i can't remember them off the top of my head.
i've also found plenty of bugs in snap working on that project, from sprites getting stuck in weird states, to errors that can't be caught with the try/catch blocks.
i'd like to go over all the issues i have in detail, but i can only imagine it turning into a bunch of arguing and getting nowhere.
agree
maye both of you have just outgrown Snap! and it's time for you to move on to a professional production language.
We have,already(js and python)
But they don't have macros....
See. Goes to show you can't complain both about lack of expressivity and "lag" in a PL.
Actually,I am just angry in the snap lag when I am making stuff that has a O(n^4) stuff in a warp in a huge forever loop
I am not angry with the lag of doing macros(they dont quite lag)
I'm sorry if Snap! and my architectural decisions makes you and @sarpnt angry. However, I'm taking it as an indicator that our job is done and you are well endowed to complain to the makers of professional programming languages about what Snap! provides that they don't.
In hindsight,I probably should expect anything bigger than O(n^2) to lag
Yeah macros are great
we dont want to parse strings and parse strings and never ends
do you mean me? because the reason i was interested in snap is to be able to make things that less experienced people could mess around with. that's the way i've approached scratch for years, to inspire people and give them readable code, but if a project gets too complex it isn't readable in scratch anymore, i was hoping snap would be reasonable.
i thought you wanted technical projects? why are you just telling people to get off snap?
who? i don't program in python.
this still really sounds like to me that you're grouping me in with them, i'm not them.
snap dissapoints me because it looked like a good tool, and had issues. what really annoys me is your attitude towards the people that actually want to use it to make new and interesting things.
if you really think your job is done and want "overenthusiastic nerds" to go away:
- get rid of suggestions on the forum. it's already done!
- get rid of share your projects on the forum. students can show their teachers
- get rid of TOTMs. students have a curriculum, they wouldn't be doing that
- stop being annoyed that projects you want to see don't exist, they're esoteric and fringe
- tell bh to stop recommend complex project ideas, they lead to esoteric fringe topics
i really think you need to actually decide who you're making snap for and make it clear it's for them specifically.
Why Isn't Snap a professional programming language? The answer is quite simple, is that is WELL beyond Snap's design parameters. Snap is meant to be, primarily a teaching tool and experimental sandbox. You're meant to play IN the sandbox not build things outside the sandbox, even if they help inside said sandbox.
That said, I do think that there should be a "professional" programming language driven by blocks, because well, if you're teaching a kid to code from age 5 with Scratch Jr and then Scratch, and then maybe they discover Snap! then for ten or so years they've been using an environment that makes a lot of sense to them and then saying, after that "Time to switch to a REAL Programming language. Nub. Good Luck" and then introducing them to the full scale train wrecks that make up those languages?
If you want to know why the drop between Scratch and Snap is so huge, let alone the amount of kids who just never code again after scratch? You show them Python or C or *Programming mess name here" and they'll rightfully look at you as if you've lost your mind.
This has been my goal for a while, a block language that runs native and can compile.
The reason I think this is is simply that programming with your hands in mixed/augmented reality via blocks is a necessary next step in the evolution of programming and that the need to cling to text languages is a destructive habit.
Mind, that's not what snap is for.
I'm bad at coding though. I've been using computers for a long time and i can navigate a UI/RTM just fine, but text strings? Brain is too broken for me to do that. I greatly enjoy reading other peoples code in snap, but when ever I open the interpreter to a blank page, all my knowledge flies out the window. Gawn.
That's a ME problem though. Otherwise I would have done it myself. I still eventually do plan to do that though, it's just going to take a couple dec... centuries... millenia...
i never said i expect snap to be a professional programming language? what you're saying isn't at all what i want.
Everybody is welcome here, I don't want anybody to go away, unless they profess "anger" and "disappointment" at Snap! or "annoyance" at me for not prioritizing their desires over those of others. In those cases I suggest slowing down and taking a break rather than turning up the volume.
Snap's raison d'être is UC Berkeley's CS10 class and the BJC curricula in their various flavors, including the Microsoft TEALS Introduction to CS course, as well as to support a dozen or so other industry, college and high school curricula and research projects. We try to make Snap welcoming and interesting so it can serve both kids and computer scientists, and also safe and predicable, so teachers feel comfortable and supported, e.g. in configuring and customizing specialized learning experiences. Some fruits hang lower than others, somer higher-ups are riper than those already in reach. So we talk to or stakeholders and glance over our long term plan and make compromises. And yes, we're also always doing everything out in the open. Every. Single. Code commit. Including every mistake and every blunder. Every little change is out there on Github for people from all over the globe to take notice. And troves of people take notice. I firmly believe writing software openly and even publicly is not just nice but right. But Lord have mercy on me when folks become so enthusiastic that they first get impatient then disappointed and finally angry because I cannot immediately fulfill all their wishes. Or because they misunderstand the - purpose of - some feature. Or because what they want conflicts with something more important.