What? As far as I know, he just doesn't like the getters and setters and create variables libraries. I'm pretty sure that's the biggest ones he doesn't like.
Of course, none of us can say for sure what jens likes and doesn't like, so I think this conversation has gone long enough.
Sorry for some bad grammar, I posted this after midnight
Yup, I want - and plan - to get rid of the "Create Variables" library, and also of the "Getters and Setters" one, for different reasons.
"Create Variables" is a band-aid kludge that helps other libraries bundle data with their blocks. Some blocks rely on the existence of a global variable to keep track of some setting, e.g. of whether string comparison should be treated case-sensitive or not. That's why when you import that library you need to first run an initialization routine that creates such a variable, or - as it's done lately - we can create such a variable on the fly. What we really need, however, is to simply allow libraries to also include persistent data, such as we're already supporting for exported sprites. Programmatically creating named variables on the fly is only a weak fix to a more general issue that we'll be addressing in future versions.
Aside from this very narrow use-case for which we've designed the "Create Variables" library the main problem I have with it is that is confuses too many users who otherwise can't program their way out of a paper bag. It looks like a solution to the problem of referring to data by a name, but it's not. Instead programmers should learn about key-value associations, data structures, and - most importantly - first-class (anonymous) data. This is especially true for learners that Snap! caters to, because programmatically creating variables on the fly is not readily supported by any other programming language they'll use later, and if you do end up tricking Python or JavaScript into letting you do it you'll be laughed out of the room or frowned upon by those who know better. The reason for that is that you don't need to associate names with data, because you already have the data and you already have a name for it. It's a so-called "tautology", an example of circular logic. The fact that "Create Variables" pops up in the libraries dialog makes it seem as if this were a good programming practice, or that there were a legitimate class of use cases for this kind of meta programming, but that's not true. So instead of educating learners we confuse them and do them a disservice by providing the library.
TL;DR: You never need to programmatically create a variable.
"Getters and Setters" is a different story. That library is now mostly redundant, because we've included almost all of its options in the primitives that are just always there already, plus many more that the library is missing. But some of those settings have been deprecated, even a long time ago, or are no longer supported. By listing those abandoned or experimental settings as options the library conveys the wrong impression that there are "secret" power switches ("smooth animations", "retina display support", ) that - in fact - don't exist (but somehow keep popping up in the forums as fake "solution").
Other settings are problematic, because they don't do what users will expect, or they can - accidentally, or by design - make you loose your work or make Snap unresponsive.
There is also a philosophical design argument between old accomplished hackers like Brian, Ken, and some others, and me, about whether everything that you can do in the IDE "should" also be doable with blocks. But that argument is mostly relevant to curriculum designers and to people giving presentations at conferences. I can't think of any good reason, why a student's mid-term project would need to programmatically resize the stage, switch to and from presentation mode, flip between different palette categories, change the "long form input dialog" or "plain prototype labels" preferences or suddenly turn on keyboard editing and input sliders or force the viewer of a project into another design mode. On the contrary, if a project suddenly does these things it's probably not what the viewer of that projects wants. In my strong opinion the programmer of a project gets to control what happens onstage, but the user of the IDE owns control over the editor. Letting the project programmer take over the IDE is disrespectful towards others and detrimental to sharing your work with others.
TL;DR: The "Getters and Setters" library is outdated, and parts of it are controversial.
"Jens doesn't want anybody using any lib". On the contrary! I've spent most of last year designing and building an extension mechanism that lets us support many more libraries! Plus, I've personally written most of the existing libraries myself:
and contributed to most others. I've even re-written the current "Create Variables" library for the new extension system.
One problem with libraries in the past has been that we relied on them too much. For example, for many years the Higher-Order-Function blocks (MAP, KEEP, COMBINE) and the FOR loop used to be part of the "tools" library, and we had to tell every BJC student to always load that library first when working on any project. So in recent years we've moved to include more features to be just "always available" in Snap. This has lead to other issues, because the number of blocks has increased, so now we need to support microworlds that wish the hide them again 
Wow, can I use that as my essay for school? 
For me, I do not want to get rid of Getters and Setters. Create Variables I agree with. I have never had to use the “create variable” block once. It is hard to use it to due to naming and values. It’s kind of useless in a sense.
Amazing project, also I mean it’s really just pinging Jen’s that is the problem, not other mods.
hello jens, ive been lingering around the 'create variables' issue for a good while now. i very much like the library and have made quite a few of my own implementations as well, my reasoning for using it (or similar) blocks is that in any programming language you typically assign variables in the script. this way you can control (block level) scope. upvars do this it seems but the idea behind
is very confusing to me, does it not do the exact same thing as the primitive 
block if it were to have a reporter in it ( 
)? why restrict to built in block just to have a finicky work around that tries to sneak returning the name of the variable just once? for example, i find:
=> 
very weird behavior. i know you can right click and view inner variables while the script is running but sometimes thats just more trouble than its worth (ending up with a screen filled of temperary watchers trying to pinpoint a value).
and associative lists, are slow. in snap, and i know ive bugged you about this before, but i just cant seem to find a good way to implement a key : value mechanism that can handle any more than a handfull of instances holding a few properties each. ...i stand corrected
theres other reasons i dont have time to get into right now but ill follow up later. for now, work in an hour gotta get ready.
That's exactly what script variables does, right? You declare a variable local to its encompassing lexical scope.
The key difference about the "Create Variables" library is that when you use the script variables block you specify the name of the variable(s) at edit time, whereas in the "create variables" blocks you specify that name at runtime, and the name itself is variable. That part - declaring a variable with a variable name is not something you do in any other programming language ever * (*except in esoteric situations).
I don't understand your point about reporters and the let block. A variable reporter is ... a reporter! (not some first-class thingy. It's a niladic function that returns an associated value. It's a function. Why would you expect to be able to assign a value to calling a function, that's a syntax error.
Ok, this prompted me to check out 'Menus' and, it is AMAZING, pff.
cough cough Script variables
Those are legitimately just script variables, not even sprite-local or global variables.
Oh. no.
I'm in big trouble.
i guess I don't understand how upvars are supposed to be handled. I remember that exact let var be val block in a library and it does just like the script variable block followed by a set variable block in one. I don't get why the variable initially returns it's name though.
and the script variables block programmatically generates names; a, b, c, ... so do formal parameters; #1, #2, #3, ... you have to create the variable and then assign it a name. I don't remember ever having to do that, it was always assignt this name to this value, not #1 create variable #2 assign a name to that variable, #3 assignt that named variable to a value. why does there have to be a whole dialog box where you type out the variable name when you could easily have it so that you can just type the name directly into the block?
Taste of his own medicine >:)
yOu DoNt HaVe PeRmIsSiOn tO ReCoRd Me
/j
Well technically I don't know where to post this.
snd? You keep on a posting that to us, so why not post it to you
You say this as if complaining about Scratch is the only bannable offense...
I mean, there are plenty more.
Omg im so sorry somebody stole my chromebook while I was in the bathroom and I was on the forums!