There is a way to inherit a local block from a parent with the block inherit or right click on the local block is the only way to acheive this?
I said that because with the inherit block we can inherit:
-local var
-scripts
-costumes
-sounds
but not local blocks...
However, I can inherit a block from the IDE like this:
Another thing: i can inherit costumes and sounds with the inherit block but not in the IDE?
I expected to find something like in the ___ of ___ block
(
)
like this:
Because local blocks are sometimes setters and are not intended for use in inherit. I believe the thing where you can inherit local blocks from the IDE may be a bug. I guess you can't do this without having to inherit manually.
If it's a bug, then why would the code not have a check to see if it's not a variable? I'd assume it's a feature.
Inheriting blocks from your parent is definitely a feature, not a bug.
In fact, it's hard not to inherit your parents' blocks. If that's not happening for you, it's probably because
That's all I can think of offhand.
I know that.
What i point out is:
(example)
create a Parent sprite with one local var and one local block
create a Child Sprite with no local var and no local block
assign a parent to the child: in the child, SET MY PARENT TO parent
future child is now an official child of Parent and inherit automaticly the local var and local blocks
but no costume and no sound
i have to use the inherit block to "import" main script, costumes and sounds from the parent
What i point out begins here:
in the child:
-if i set the local var to a value: the var is now unherited (normal), but if i change my mind, i can heritate it again with the inherit block
-if i change a costume or a sound, i can heritate it again with the inherit block
-if i change the main script, i can heritate it again with the inherit block
BUT
if i change the local block (and i change my mind after), i can't heritate it again with the inherit block (no option...) (i can inherit again by right clicking on the local block\inherited but not with the inherit block).
That's my point...
I don't understand why we can inherit everything except local blocks (with inherit block)...
Oh, sorry, I was talking to @ten_6044, not to you! By the time I finished that part (after several interruptions) I forgot that I hadn't dealt with your original message. Mea culpa!
This was a surprise to me. I could have sworn costumes and sounds were inherited by default!
You're absolutely right. I would have expected this to work:
That did work once upon a time, I swear, but maybe it was in BYOB 3.1.
While we discuss this topic:
Don't you think it's too easy to change from a inherited state to a non-inherited state (without really meaning to) just by moving a block in the script area (1mm)? (main script or local block script)
And there is no visual clue that the current script is inherited or not? see this
I think the programmer should explicitly know if he is in a inherited environment or not. This could be done by changing the color of the blocks in the scripting area. (Same as the IDE does for an inherited local block or inherited variable in the palette)
like this ? (but in the scripting area)
or
you can now use the delete block block to programmatically let a clone inherit a block:
I agree that it would probably be a good idea to also the the inherit block do that. In general I used to be extremely reluctant to let users programmatically delete block definitions, because this is dangerous and might lead to massive and irreversible loss of work.
Side note: This is also the reason why I'm very reluctant towards all these wise remarks about "Eisenbergification" (the alleged "rule" that states that "everything" that can be done in the IDE "should" also be a feature of the language). I have the impression that people who vehemently demand metaprogramming capabilities for everything cannot have been inside an actual school room with children and - more important! - with an actual teacher who needs to complete an actual lesson with 20+ children over the course of 40 minutes while dealing with technical hiccups, noise and discipline issues, different learning speeds, motivation variety etc. etc,.
As a rule of thumb: If you feel you must use metaprogramming to achieve something you cannot otherwise accomplish, you're probably overthinking it. That said, I love metaprogramming myself, and I'm very excited about making it even more expressive in v10.
About the side note, I don't see what metaprogramming has to do with Eisenberg's Law, or vice versa. Metaprogramming is a programming language feature, the need for which arises even in 60-year-old text languages without IDEs. Eisenberg's Law is specific to direct visual control environments that have extension languages, such as MS Word macros and the Snap! IDE.
I've been in classrooms with kids and teachers. I don't think anyone is suggesting that all the most advanced features of Snap! will be used in the middle of class, but I can easily imagine a teacher using them ahead of time -- and so can you, because you believe in these ill-named "microworlds" wherein blocks are hidden programmatically. Eisenberg's Law FTW! :~)
I feel like the main difference with those and snap, is that text programming languages tend to have nondestructive metaprogramming, whereas snap has destructive metaprogramming. What I'm saying is, text languages usually have a snapshot of the program before running, and do not change on the filesystem while it's running (usually, I'm pretty sure there's some way to do that). Snap, on the other hand, does not save a snapshot of the program before running, so any metaprogramming will stay after running, and can delete important scripts with a much harder way to revert back. You just need to have saved the project before running.
I feel like this is a much better representation on what snap's metaprogramming is like.
Yeah, I specified old text languages to try to avoid the confusion between metaprogramming and incremental development in an IDE. I think Jens is just about old enough to remember what I mean, but let me spell it out for you.
In the old days, programming language compilers didn't have any kind of editing capability built in. You edited your program in some external program, Emacs or (these days it'd be) TextEdit or Notepad (not a document formatter such as Word), and then ran it through the compiler. So there was no danger of the compiler modifying the program code. (Cf. Kernighan C compiler hack.) It's because of this history that when someone had the idea of combining the compiler with a special-purpose text editor that understands the language's syntax, they had to make up a name for it, "Integrated Development Environment."
The point of macros ("metaprogramming" has too many letters for me to keep typing it) is to extend the language. They let users be their own language designers. Using a macro capability to change the definition of an existing procedure is not what it's really for; it's to make a new syntax. As an analogy, imagine if raw Snap! let you have only one C-shaped slot in a block, but you could write a macro to allow more than one. That'd be inventing a new syntax. (I'm emphasizing syntax because in any reasonable language you can invent new semantics with plain old procedures; no need for macros. But yes, another use for macros is to invent programmatically a family of procedures not involving new syntax.)
What counts as syntax is way more complicated in a visual language than in a text language, whose programs are ultimately just text. Snap! 's macros don't let users define new block shapes, input slot shapes, or shapes period. But those shapes represent categories that can be invented in a text language. Maybe, over a long time, one by one, we'll end up feeling the need to invent macro-like graphics features. Or maybe not.
Indeed, Snap! metaprogramming (the part about letting you create a block) is an example of letting users do programmatically something they could always do in the UI. (The other half, letting you examine a block definition programmatically, isn't an instance of Eisenberg's Law.) But the point of the Law is that everything you can do in the UI should be doable in a program. For example, although Jens loves a programmable equivalent to the "Make a block" button, he hates the whole idea of a programmable equivalent to the "Make a variable" button. ¯\_(ツ)_/¯
I mean, I can see how there might be a few exceptions. Consider password managers, which let you see your saved passwords for different sites. Yeah, there probably shouldn't be a web API to retrieve those passwords programmatically. Maybe there are a few such exceptions for Snap!, too. But Eisenberg's Law says that by default, if you can do something in the UI, you should be able to do it in a program also. One reason to make it a Law is that if you're in the habit of thinking that way, you build your UI in a way that factors the actual doing of whatever it is from capturing the mouse click that tells the UI to do it, and then you can (using a macro! :~P) automate exposing the action in the programming language. It's the other direction that's hard, because you have to design an appropriate UI, a dialog box or a slider or whatever, for each action.
A while ago there was a thread asking for a block equivalent to the "pic" option in the stage's context menu
Turns out there is such a block, kind of, but it's hidden in dev mode:
Why is it hidden in dev mode? By default every item in every context menu should have a block equivalent. That doesn't have to mean a zillion different blocks; there could be a block
in which the choices in the ITEM slot would depend on which menu was chosen in the MENU slot. Or something; this is an off-the-cuff idea rather than a careful design.
this answer is exactly the reason why I'm growing ever more reluctant about any sentence that posits that "everything should..."
If you want to build the programming language to end all programming language, fine, but it won't be Snap. Are you folks aware of what's being taught in schools to a whole class of kids who need to pass an exam afterwards, not just to the 2 exceptional boys who are gifted mathematicians already?
these a difference here i think in what is the goal, if the goal is strictly the grade, then the content is useless afterwards and will be forgotten. if the goal is to appease to these kids whose goal is to get the good grade, you are actively working towards helping these kid get to the point where they get to forget everything youve presented them with! if the goal is to really learn about programming, well, what is programming. im not going to get in to that super deep, im just going to say what i think, programming is making the computer do whatever you want it to. because thats what you can do. just about... so the goal here could be anything. some people want to make a game. some people want to make tools. some people want to see what happens when you do this with that or what about that with this. playing around, stretching their creativity past beyond the bounds of certainty. but now what happens when you get in the way of that goal? say your goal is to stop them from being able to do something. well now they think, 'they wont let me do this thing i want to do. i wonder how i can still do it anyway?'. and now youre actively working towards helping these kids want really bad to do this thing you dont want them to do. and the beautiful thing is this, snap is just a program, the only thing in the way of them doing the thing is them figuring out how to do it. and when you get someone like me, who actually knows a thing or two about programming, i just do the thing. no permission granted, wonderful, no permission needed! what i dont understand is why you want people not to be able to do what they want to do? am i getting this wrong because it doesnt feel right. but its what it seems like. i do want to believe your hearts in the right place but clearly its not getting through correctly
enable js (obviously)
edit: ok the second dropdown doesnt work with iframe. lol heres the project link. should work in the editor.
edit2: ok it work in the iframe but you have to move the block. lol. idk. but is this what you were talking about?
I love the way you did the [item] dropdown. I wouldn't have thought about putting a JavaScript function in there, but if it works, it works!
Yes, this is exactly what I‘m talking about, thank you. Imagine opening a project that all by itself changes the language, hides all blocks, constantly writes tons of files to your disk, etc. and think about what this would do to a classroom with one teacher and 25 kids getting to use Snap once for 40 mins per week. As you continue to discover, there is obviously nothing I‘m doing that prevents you from writing everything and anything you can imagine or want, and I‘m even giving you a JS function block (that‘s my proud invention, imagine that!) to make such extensions really easy and interactive to develop. I so don‘t understand all this bickering, all I‘m refusing is to include dangerous stuff that might cause kids to massively lose work or that might overwhelm users with unexpected behavior or cognitive load in the default configuration, and I do take issue with folks claiming that I should. Are you a teacher? Have you taught somebody else‘s curriculum (not your own fav project) to kids who have to be in your class and pass it wherher they want to or not? I want Snap to be a welcoming, inclusive and safe playground to learn powerful ideas in computing, not just something for the few savants who already know everything.
no i am not a teacher, havent taught someone elses curriculum to kids being forced to take it, i still think that accomplishes nothing... im not saying you did this shame on you but its really sad that something as joyous and fulfilling at least as i find it, is being used like this, kids have to do this, that take the fun all out of it. thats what makes people hate it, i hate doing what i have to do, especially if i know the only reason i have to do it is because someone else has the power to make me do it. all so employers who think they can milk the electricity out of the creative types can ground them and wonder why they arent being shocked..
i do love to teach people how to do something i know and they want to know, thats the best, most fun, most satisfying thing ever. and its easy. theres nothing in the way. theres also no pressure. if they change their mind and decide they hate it all is well. but schools i still feel like do an awful job at teaching children. maybe im just still not over the fact i wasted the majority of my time for 12 years sitting quietly learning how to pass my classes so i could immediately forget everything because i didnt care about it nor found it applicable in my own life. now im an adult and get to realize all the things i do need to know that i dont and pretty much have to figure out myself. but at least i know our first presidents name. go frickin me right.
I'm impressed by how little code that required!
It's a good start, but doesn't include context menus. That's much trickier. The hard part is specifying what menu you actually want without clicking on something. As a first attempt: Your Menu menu needs a "background of 
︎" submenu with entries stage, scripting area, and palette. Users should be able to ringify a block or script; if it's a single block maybe you should offer the union of that block's context menu when in a script and (then, after a horizontal rule) its context menu when in the palette. To make Jens happy, for all menus, filter out anything with "delete" in its name. :~) And your Menu menu should also include a submenu for each sprite with entries such as on stage, sprite corral, current costume... you get the idea. I suppose there should also be a Button choice in the Menu menu that lets you choose green flag, pause, stop, visible stepping, new sprite, paint new sprite, photo new sprite (we're leaving out the trash can). And a per-sprite submenu that gives you buttons such as Draggable, Revolve, Don't revolve, Face left-right only.
But also, all the items with "..." in their name open a dialog for the user to control something or other. In those cases you really want a third input slot for the user to put the value in. (Could be an expression that computes it.) And, you know, if the dialog has checkboxes, a way to check them.
All this extra complexity is a reason for Jens not to like the whole idea. If we were a text language instead of a block language we'd just have specific primitives for each thing a user can do. It's trying to minimize blocks that makes this hairy. There could be compromises such as SPRITE _ STAGE CONTEXT MENU ITEM _ as a block.
Probably you shouldn't actually do all this, so as not to cause Jens's head to explode. I'm just explaining my side of the argument, i.e., Eisenberg's Law.
Jens, I really, honestly, don't want to make you angry. I hate when that happens. (I mean, I hate when I make you angry. I want to be better at being able to express ideas without pushing your (or anyone's) buttons.)
But I've always thought we were agreed that we could meet everyone's needs, the 2 boys (who are occasionally girls, by the way) and the teacher of 30 (or of 3000, in peak years at Berkeley). That's why we reached the compromise of requiring turning on JS for this one library, so nobody would trip over it.
Nobody is asking for that. That's the point of requiring turning on JS. But I do think everything should be accessible, no matter how many handsprings you want users to have to do first.
You say "should" all the time, too, except more often it's "shouldn't," as in "people shouldn't use the variables library." :~/ We all have ideas about good and bad programming styles, but we decided early on that we're not Pascal, or even Racket; we don't enforce our opinions on users. I'm not saying you're doing that! But right now you're talking as if you were doing it: we have to restrict people to the style of work appropriate in a classroom.
Speaking of which, although I would express myself less vehemently than @cameron8299, especially right now when you're angry, I really don't believe in the way most classrooms work, as you know. When even you, who have right ideas about teaching, find yourself talking about passing exams as the reason things have to be a certain way, that shows me that the context in which you're teaching -- not your fault! -- is terrible. Your argument should be that some proposal gets in the way of kids understanding things, not that it gets in the way of them jumping through hoops. Cart before the horse. If we language designers, the curriculum designers, and the teachers are all doing our jobs, the kids will learn the ideas, and as a result they will pass the exam. Better still, we'll build learning environments without grades and exams. I know that won't be easy, and I'm not saying it glibly. It will require a huge movement among teachers, and take time. But still, I want to be part of that movement, marching in the street, not in the schoolhouse barricading the doors.
Anyway, the point of these getters and setters isn't to teach them to kids. If you recall, long ago, when I was working on tutorial videos (one more thing I have to get back to, groan) I wanted switching to the next part of the tutorial to be able to switch into or out of presentation mode. I think I did convince you to add that feature, although it must have been back in BYOB, because it doesn't seem to be in Snap!, which just shows you how long it's been since I worked on those videos. But when my psychiatrist finds the right medication and I get energetic, I'll want that again! That's the sort of use case I'm anticipating, and I don't think I know in advance exactly which setting other people's programs will have to change.
Social. It's a thing, you know. It's
and
that trigger my vehement objection. Your and a few others assumption that you "should" be able to do "whatever you want to do" in Snap, and that if there's anything that requires even so much as climbing over a fence - such as switching to dev mode or enabling JS-functions - then it must be evil. That's such a "Wild-West Cowboy" attitude! Your projects don't just run on your own device, they - often! - get shared with others, and that social community aspect calls for a fair balance between your desire for total control over your computer and your peers interest in not letting your project take over theirs.
I'm getting defensive when you give the impression that I'm "not letting" you do whatever you want in Snap. I even made it so that by friggin' default JS-functions are enabled(!!!) if you run Snap! locally, because in that case there is zero danger of them harming anybody else.
I actually somewhat agree that some things shouldn't be given to the programmer. Things like, logging in, opening a project, loading a library,, enabling javascript etc, might not be in the best interest to trigger via code. There are other things that I do think can be exposed without harm, like changing the stage size, codification, maybe even the generate puzzle function (which I still don't quite understand).
There has to be a line between what should and shouldn't be exposed to the programmer, as many things just don't make sense to expose, or are dangerous. After all, the snap IDE has an account system built into it, and you don't want your account to be haxked.
