You guys are cool (devs)

[cameron8299]

first and foremost i want to apologize to @jens and @bh for being so critical, rude, and inconsiderate towards snap and anyone whos put their time in to making it into what it is. i want you to know though, i do appreciate snap, a whole lot, ever since the day i discovered it. its seriously one of the coolest, most satisfying, and intuitive environments to learn, experiment, create, and just mess around and see if something interesting happens. and i cant emphasize those three points enough,

ever since i started making bigger more polished projects in scratch, i dreamed about making custom c blocks, custom reporters, lists containing other lists, local variables, etc etc etc. how cool would that be. and here's snap, doing all that, and also, doing things ive never even dared to dream of, like having freakin' variables in the block that you can set in the definition and drag from the block instance to use further down in your script?? i love that. i love all of the cool extra and even experimental features added and that i would get to learn how they all worked and ultimately how i could use them to do cool stuff. like continuations, which even though i dont really use them, i remember trying to understand them, not getting it, getting frustrated, over and over until i started to see how they actually worked and what purpose they served, and that alone was super rewarding and i think opened my mind a little bit towards programming in general and taught me a new way to think about potential solutions to problems i might face in the future.

and my god snap just hits so many sweet spots for me. i always found scratch incredibly satisfying, and you guys maintained that quality very well with all the new features added on top of what was already there. i think if you dropped someone completely unaware of scratch, into snap, they wouldnt be able to tell that it was an extension of another language. it all feels like it fits together seamlessly. like you should be able to do all this 'extra' stuff, you should be able to make c blocks, reporters, nested lists, local variables, and maybe its just from being unable to do it before, but having that all just work, just pick what you want and its there, its like music.

and intuitive i think is pretty self explanatory. you literally see the sequence in front of you and can move parts around any way you want.

so i feel bad for making it seem like it just wasnt enough. after doing all this and all people can say is 'you forgot..' or 'why didnt you add...' and talk and talk about all the things you didnt do. which im sorry for contributing to that detriment. the truth is, at least for me, i get so excited about little things like the color input, the if else variadic block, this new custom primitive thing dont get me started, i guess in my head, if i were to make snap, i wouldve done things in a different order. which is wrong for me to expect your priorities to align with mine. i guess the reason i was upset is that it seemed like you were just withholding features, like we can see the color input in the pen blocks but thats not for us to use.. kind of like how scratch was frustrating in the same way, having features that we just dont get to get our hands on. but i get it. it takes time. and if you really wanted to you could change the input token in the console/dev mode. you can do all the things that dont have their own ui or dialog box or whatever, if you really want to. and i do, thats another thing i really do appreciate about snap, that i can make stuff like this just because i want to see it work and what it would look like. i think thats about it thanks.

[sathvikrias]

@cameron8299

we can see the color input in the pen blocks but thats not for us to use

We can do that now!

[cameron8299]

i know. i was just reflecting on how i used to complain about not having those features. and i feel like they get that alot so i want to say sorry and show some appreciation.

[sathvikrias]

Ok

[mac10fan]

@cameron8299

i want to say sorry and show some appreciation

It's okay, we all make mistakes sometimes

[bh]

Thank you!

We really do think hard about the user interface and about how to try to make advanced ideas more intuitive visually. I don't think Engelbart himself could make continuations intuitive, but I'm really super proud of what a list of blocks looks like. Even if you've never thought about procedures as data before, if you're a Scratcher you see that picture and it's just obvious what you're seeing.

Jens is a brilliant programmer! We're so lucky to have him.

When we provide a zillion options, it's easy for things to get lost. We were surprised recently to discover that a very experienced adult user didn't know you could shift-click on the variadic input arrowheads to get three at a time, but we shouldn't have been surprised, since there's no visual clue to make that discoverable. The rest of the world seems to be solving that problem by asynchronously popping up speech bubbles with hints, always right on top of the thing you're trying to work on just then. I hope we can avoid that. :~)

So if you had a UI suggestion for how we could allow input groups (such as your var=value pairings) in a discoverable way, that'd be great! :~) It's one of the things we're thinking about, not for right away but down the road.

P.S. I would have done things in a different order, too, if we'd been starting from scratch instead of from Scratch. As it is, we've tried to make each new thing comprehensible to Scratch users. Otherwise I'd have preferred for every block to be a reporter!

[cameron8299]

well ive always liked the let (var) be [val] block in one of the librarys quite useful. because alot of times when im making local variables i have an initial value i want to set it to, and also quite often theres multiple local variables i want to make and potentially set initially to something. but thats really just my preference i think and that block was just an example of being able to really get into the inner workings and just try things out and see what they would look like. so i dont think that particular block really needs to be a thing since you can make a let x be y block, and just use multiple of those for multiple vars.

but i do think theres alot of real estate that could be used inside of context menus. theyre nice and out of the way and you can also categorize things further in sub-menus. i like being able to right click things and configure them, like the relabel i think its called where you can change like a + block to a - block is extremely useful. but for example, the lists, or any multi input slots, i think would benefit having an option to set it to multi line vs inline. because if i want to do matrices, or just array of arrays, i found this trick to get multi line inputs but its kind of hack-y;

you also have to un-ringify each of the inner lists to get it to work. also, just tried setting the seperator to $nl but

but im not gonna let myself get carried away trying to think up ideas. next time something comes to mind though ill make a feature request or something.

and also im really curious how only reporters would work?

[bh]

@cameron8299

and also im really curious how only reporters would work?

Everything would be the same as now, but the current command blocks would do what they do and also report a value. Like, for example, MOVE n STEPS might report the sprite's position. But even if a particular block had nothing useful to report, it'd just report a null.

The block shape would be an oval with tabs; I'm reminded of those fish-with-feet bumper stickers people who believe in evolution use to respond to the regular fish ones that more literal-minded Christians use. So you could attach them vertically to make a script, but you could also put one in another's input slot.

This is how Lisp works; every procedure returns a value. The body of a procedure is a sequence of procedure calls; the values of all but the last are ignored.

In the beginning there was Fortran, in which the assignment operator didn't return a value, so you couldn't nest assignments like

a = b = 7

but then someone (C maybe?) had the idea of making it a reporter, in Scratch terms, so that b = 7 returns 7 and you can assign that to A.

One motivation for this idea is that it encourages, without forcing, functional programming, so instead of writing

as a sequence of separate actions, you write

so that you are making a new list instead of mutating the old one.

Advantages of functional programming:

1. You have way fewer bugs because you don't have one part of a big program clobbering a value that another part of the program is still using.

2. It's easy to take advantage of parallel hardware by computing all the inputs to a function at once, rather than the first one and then the next one etc., because you can be sure that the computation of one input doesn't change some variable that affects the computation of another one, so you don't care what order things happen in. There aren't any critical sections of code during which you have to lock out other threads.

3. It's just a more powerful way of thinking, especially if you have some deep data structure, such as the lists you get from SPLIT BY BLOCKS, and you can use recursive functions to let the computer keep track of where you're up to in the tree instead of writing explicit code for that.

My favorite anecdote about this (slides from Brian's Last Lecture): Back when I was teaching Structure and Interpretation of Computer Programs as our first course for CS majors, one semester I was also teaching the sophomore data structures class using C (this was a long time ago) and I gave this as a midterm exam problem:

... and almost everyone got it wrong, because they were trying to write an iterative loop to traverse the tree. So, next lecture, I said, "okay, everyone take out a piece of paper and write this program in Scheme." And they all groaned, because they hadn't used Scheme in a year and they thought they had forgotten all about it, but after a lot of grumbling most of them could write more or less this:

So I wrote that on the board, and then picked up the yellow chalk (this was a long time ago) and wrote in between the lines:

and they said "but C doesn't have CONS," to which I replied "come on, you know how to implement linked lists in C." Which they did, all of them. They just couldn't solve the problem in C because they (mostly) all though that the SICP course was a course about Scheme, rather than a course about ideas. I can't promise that I convinced them all, but I convinced the smart ones.

Sorry, you pushed one of my buttons. :~)

[cameron8299]

@bh

Untitled script pic (4)1314×490 93.8 KB

dont recursive functions introduce overhead? is it more about the idea or does this optimize somehow?

[cameron8299]

@bh

Everything would be the same as now, but the current command blocks would do what they do and also report a value. Like, for example, MOVE n STEPS might report the sprite's position. But even if a particular block had nothing useful to report, it'd just report a null.

also im definitely going to try and do this now

[bh]

@cameron8299

dont recursive functions introduce overhead? is it more about the idea or does this optimize somehow?

It optimizes human thought. Consider this variation:

I challenge you to write that function iteratively! See how long it takes you to write and debug it.

@cameron8299

also im definitely going to try and do this now

You can use regular Snap! reporters to make a script with