enable javascript, play around with it, but dont use in your own projects. these blocks will turn to undefined when you try to save / load. it may even fail to load completely and lock you out. if you want to use these elsewhere anyways just make sure you save before you put these blocks in and keep that as a backup.
anywho
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...
hey it may be rough around the edges but it serves it's purpose. it's not meant to use it's meant to show the possibility of an implementation like this that I find very visually and conceptually pleasing, beautiful (isn't that something you want too?) like the rest of snap. the library is a make-do workaround solution in my eyes and I'm using javascript because that's what snaps written in and it's the only way I know to do the things that snap doesn't yet yet provide a way to do. like fully customizable inputs. which I will push until it happens or I just end up making a full fledge mod through figuring it out myself.
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:
LIST
ITEM n OF
NUMBERS FROM
Functional list reporters
IN FRONT OF
ALL BUT FIRST OF
MAP
KEEP
FIND FIRST
COMBINE
Imperative list commands
ADD
INSERT
DELETE
REPLACE
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!).
To help you, or really anyone on here, know how it's spelled.
Maybe the second, but not intentionally. However, I am a linguist, (as my shirt says, (in IPA): "trust me I'm a linguist") and I can't help spotting spelling and grammar mistakes.
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:
wanting
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.
=> 
=> 
=> 
=> 
