simple idea ive always wanted in snap;
=> => => =>
and ive made a few different attempts at creating it, but i finally got something that works as intended, at least as far as basic functionality goes.
technically, its a procedure, not a function
@bh is there a procedure equivelent to the word 'functionality'? i want to say procedurability but that just feels wrong
You're allowed to say "functionality" about anything, even real physical things, not just functions. But imho it's an ugly word, one of those staff-meeting words; I prefer "purpose" or "effect" or "what it does."
Speaking of preferring things, I prefer the written-in-Snap! "Multi-branched conditional" library over some flaky JS thing that you can't save...
Oh, yeah, I agree with all that. I was just reacting to all those warnings in your original post: Here's this beautiful thing but don't try to use it. The library has the great advantage of actually working!
And also, on the subject of elegance, I find it awesome that a control structure like this can be written entirely in Snap!. Starting in BYOB 2.99, even! That's one of the things that convinced us that we were going in the right direction. And invented by a kid! (Not just any kid, I grant you.)
yeah i try to make it a clear distinction between my native snap projects and my modifications, because i love adopting both styles but i think jens was trying to make the point the other day that they really dont mix. like, ' hey , look what i did in snap ' vs ' look what i did to snap '. i seriously do believe that there are major some untapped integrations that could be made though, greatly expanding snaps flexibility and without giving up that simplicity. i feel that it would be nice to have more complexity tucked away for those who actually find interest in such things, like how youve go the atan2 function included but not put up on a pedastool(no clue how to spell that) in the main palette or even the other math functions in the dropdown so that you can still do trigonometric calculations without having the operators category littered with sines and cosines.
what a weird question. ive never been asked that before. who are you quoting, google? autocorrect? it didnt show up in mine and im not breaking my train of thought just to spell something a different way than what i intuitively feel like makes the most sense for it to be spelled, when it would make no difference in getting whatever point im trying to make across. because you clearly know what i meant and for some reason cant help yourself seeing someone make a minor mistake why just why do you have to point it out? does it make you feel better about yourself? look smarter? what do you or i have to gain from you pointing out a mistake that is 1 unimportant and 2 had already been acknowledged? god like i wrote the whole rest of that comment and you want to talk about the correct spelling of the word "pedestal". give me a break
Yes. For example, better integration with robots and robotish things.
The question is how to retain the simplicity. I think custom categories may help, although a lot of them can also be overwhelming. (And we should separate variables from lists.) I also think hiding some blocks behind arrowheads, like this:
ITEM n OF
Functional list reporters
IN FRONT OF
ALL BUT FIRST OF
Imperative list commands
Note, I'm not arguing strongly for this particular example, which may be hiding too much. But it was the first example that came to mind, and I'm arguing for the general idea of little arrowhead things.
Would you like to suggest extensions and/or visual aids for controlling complexity? I don't much like the recent Scratch technique of taking things that really belong in the core language and turning them into extensions (e.g., turtle graphics!).
one thing i think would really help is utilizing dropdowns, so that you can do sort of like how 'relabel' does where you change the block but not necessarily changing the block itself but rather its parts. what i mean is kinda like this. (there are two sprites with examples)
another thing, collapsible slots, so that if you had a big piece of data you could hide it away and focus on the script. or like in some text editors that support code folding, c-slots could do something similar. i dont have the time to make an example but would look kinda like
last thing i can think of right now is having a way to see what an input does. like hint bubbles
(my screen capture doesnt capture my mouse pointer for some reason)
or maybe a placeholder text thats greyed out, would be very useful if you had a block with a lot of inputs
oh, and i think you should be able have blocks as default inputs. so if i had a custom ( point ( x ) ( y ) ) block and another ( poly ( ...points ) 🢒 ) block there would be a way to automatically have each input set to my custom block, and maybe even restrict it to certain blocks so it would be clear i have this input that accepts this data structure and instead of accepting any block which would just throw an error, just accept the ones the block is designed to handle.
i usually do a weird read only number input that has; just look:
or something similar
i know im missing some things ill probably think of later , ill try to remember to let you know when i do. more abstact ideas but i got to come across them i cant just remember them at will. which really is too bad.
That's a cool idea. I think the use of arrowheads needs work, because they're already commonly used for variadic inputs. But that's a detail that could be worked out. Maybe a huge rightarrow with a tiny picture of a two-command script inside it? Something.