Scratch

bharvey · 2010-10-21 01:08:11

fullmoon wrote:
I see how the two are different in that sense but they appear to function exactly the same to me.... So from my understanding, unevaluated arguments are basically a shortcut for wrapping certain inputs in "the block".

Ah, okay, I think I see why we're at cross purposes here. I totally agree with everything you said except for the word "shortcut." Grey borders are a shortcut for THE BLOCK, but the purpose -- the user interface purpose -- of unevaluated inputs isn't to be a shortcut, but rather to be a hiding mechanism.

Consider this: C-shaped slots are, as we now know from the BYOB experience, unevaluated inputs. (What's inside the C-slot is a script, but it doesn't look like a script -- at least, it doesn't look like a BYOB script-as-data in a grey border.) But if you can think back to when you first learned Scratch, I'll bet that that never occurred to you. It's not exactly that you thought they were evaluated; rather, you didn't really have evaluation as a concept in your head at all.

What you keep saying, correctly, is that from the computer's point of view an unevaluated input is no different from a procedure-type input. Then you take a misstep from pure computer science into user interface design by thinking, "since they mean the same they might as well look the same." That would be true if people were just computers, but actually people, especially ones who are just beginning at programming, build up mental models quite different from what's going on under the hood. This is a good thing! After all, what's really going on under the hood is a bunch of electrons whizzing around through remote-controlled switches (that's essentially what a transistor is when you're in the digital domain), and we don't want our beginners, or even our adult professional programmers, to have to think about that.

So, try to put yourself in the shoes of a beginner, who has no notion of "evaluation" in his/her head, and who is confronted with a block of the form

Code:

IF <condition> THEN <value> ELSE <value>

In this three-slot block, the last two slots have grey borders around them, while the first one doesn't. What do you make of this? Well, (a) something scary and complicated is going on, and (b) grey border means "non-Boolean," maybe? Or grey border means "maybe"? Or grey borders mean "mutually exclusive"? Anyway, not what we want people to think of when they see a grey border. And, by the way, if s/he is taught to think "function" about grey borders, then s/he will be confused by the fact that it's a function of no arguments -- not something you usually see in mathematics.

From a user interface standpoint, the situation is quite different when you see a grey border in, say, the MAP block. You're not going to make sense of MAP at all unless you already believe in functions as data. In the MAP block, the grey border is a welcome reminder that this one is the function input, as opposed to the list input.

Does that help?

Last edited by bharvey (2010-10-21 01:40:04)

bharvey · 2010-10-21 01:16:22

fullmoon wrote:
This is more or less my third example, I just left out the "lambda" keyword because I don't think my parser needs it!

Oh! I misread that example because I got the parens and braces mixed up -- there are quite a lot of them. smile I thought the formal parameter was grouped with the each message rather than with the body, so it didn't look like a lambda to me. Now I get it.

Jens · 2010-10-21 03:57:10

fullmoon wrote:
I just left out the "lambda" keyword because I don't think my parser needs it! For clarity, though, I think I'll end up marking blocks/functions with a "@" symbol, because it doesn't seem to be getting much use anywhere else. I've also left out the colon-delimited arguments and I'm opting to go C-style, although we'll see what Jens can do to get me to change my mind

Hmm, syntax aside I like an explicit keyword like "lambda" better than a single character, especially one that's so overloaded with meaning like @, which I still read "at" as in Smalltalk's Points (x@y) or in e-mail addresses (name@domain). Since your C-syntax DSL somehow resembles JS How about using "function" as keyword? smile

fullmoon · 2010-10-21 12:11:07

@bharvey

I'm beginning to see what you mean when you say that unevaluated inputs are a hiding mechanism. After all, the primitive "repeat until" block takes an unevaluated boolean input, but you would never notice unless you were really thinking about it from another perspective! So keeping unevaluated inputs in the form they are now is really just another step in integrating BYOB with the way Scratch was designed.

@Jens

^ There's that "@" symbol again...perhaps I will rethink using it. But one of my least favorite things about Javascript is the function keyword -- it feels clumsy.

^ I'm also using "^" for "return".

bharvey · 2010-10-21 12:26:55

fullmoon wrote:
After all, the primitive "repeat until" block takes an unevaluated boolean input, but you would never notice unless you were really thinking about it from another perspective!

Yes, precisely. For a while, before we invented unevaluated input types, we used grey hexagons for things like REPEAT UNTIL (as opposed to white hexagons for IF, which is happy to get an evaluated input that it uses once). Once we could think of the REPEAT UNTIL input as unevaluated-Boolean, rather than as Predicate type, we went back to white hexagons with a sigh of relief.

fullmoon · 2010-10-21 13:31:02

@Jens

Just had a Smalltalk epiphany moment. I was freaking out over the syntax for conditionals, when I realized I could actually create a method of the boolean type called ifTrue!
big_smile

EDIT: I realize that this is pretty much completely off-topic, but I've chosen a syntax for blocks:

Code:

(
    say_hello_to = |name|{
        ^"Hello, "+name
    }
)

So the forEach example from earlier will look like this:

Code:

poemFragments forEach(|fragment|{
  io out("One flew over "+fragment)
})

Last edited by fullmoon (2010-10-21 16:04:37)

Jens · 2010-10-21 19:00:34

Wow, I love Smalltalk epiphanies like yours! Isn't it cool how you can build your own programming language out of lambdas and evaluating them? I also like your leaning towards Smalltalk syntax with the caret for return and the vertical bars for temporaries. Can't wait to try your new scripting language!

P.S. I voted for you smile

bharvey · 2010-10-21 20:40:30

fullmoon wrote:

Code:

poemFragments forEach(|fragment|{
  io out("One flew over "+fragment)
})

Jens wrote:
I also like your leaning towards Smalltalk syntax with the caret for return and the vertical bars for temporaries.

Wait, he's using vertical bars for formal parameters; that's not what Smalltalk does, is it?

bharvey · 2010-10-21 20:41:46

ProgrammingFreak wrote:
I Am Dumb!!!!!!!

What's this about? Anything to do with BYOB?

Jens · 2010-10-22 03:43:21

bharvey wrote:
fullmoon wrote:
Code:
poemFragments forEach(|fragment|{
  io out("One flew over "+fragment)
})
Jens wrote:
I also like your leaning towards Smalltalk syntax with the caret for return and the vertical bars for temporaries.
Wait, he's using vertical bars for formal parameters; that's not what Smalltalk does, is it?

Well, in Smalltalk formal parameters for Blocks are indicated by a colon prefix each and separated from the Block's body by a single vertical bar, so there's one vertical bar in how this would look in Smalltalk: smile

Code:

poemFragments do: [ :eachFragment |
    Transcript cr; show: 'One flew over', eachFragment ]

or, if you wanted two formal parameters, you'd code something like this:

Code:

| print join firstNames lastNames |
join := [ :firstString :secondString | firstString, ' ', secondString ].
print := [ :line | Transcript cr; show: line ].
firstNames := #(John Paul George Ringo).
lastnames := #(Lennon McCartney Harrison Starr).
firstNames sizeRepeat: [ :i | 
    print value: (join value: (firstNames at: i) value: (lastNames at: i) ].

Last edited by Jens (2010-10-22 03:54:08)

Guinea_Pig_Girl · 2010-10-22 04:32:02

Umm...wow. That is so complicated...(To me. XD) but yeah. I love BYOB!!!! smile It's just so...easy! Press make a block, set the types, program the block, that's it. A great mod of Scratch! big_smile

bharvey · 2010-10-22 09:59:22

Jens wrote:
Well, in Smalltalk formal parameters for Blocks are indicated by a colon prefix each and separated from the Block's body by a single vertical bar, so there's one vertical bar in how this would look in Smalltalk:

Huh?

Code:

gotoX: x y: y

    self holdSubsprites.
    offset ifNotNil: [
        offset _ offset + (x@y - self referencePosition) ].
    self referencePosition: x@y.
    self releaseSubsprites.

Actual copy-pasted code. Two formal parameters. Zero vertical bars. Those things in your examples aren't formal parameters, Jens; they're script variables.

bharvey · 2010-10-22 10:03:17

Guinea_Pig_Girl wrote:
Umm...wow. That is so complicated...(To me. XD) but yeah. I love BYOB!!!! It's just so...easy! Press make a block, set the types, program the block, that's it. A great mod of Scratch!

Thanks! That was the goal. Try out the tutorials and see if you learn to love the THE BLOCK block and the THE SCRIPT block. smile

A program like Scratch or BYOB that does so much, with such a fancy user interface, is going to be complicated "under the hood," but it's just a lot of details to keep track of, not magic.

fullmoon · 2010-10-22 11:31:36

bharvey wrote:
Jens wrote:
Well, in Smalltalk formal parameters for Blocks are indicated by a colon prefix each and separated from the Block's body by a single vertical bar, so there's one vertical bar in how this would look in Smalltalk:
Huh?
Code:
gotoX: x y: y

    self holdSubsprites.
    offset ifNotNil: [
        offset _ offset + (x@y - self referencePosition) ].
    self referencePosition: x@y.
    self releaseSubsprites.
Actual copy-pasted code. Two formal parameters. Zero vertical bars. Those things in your examples aren't formal parameters, Jens; they're script variables.

I don't know nil about Smalltalk ( big_smile ) but to me that looks like a formal method definition rather than an anonymous block.

bharvey · 2010-10-22 11:54:01

fullmoon wrote:
I don't know nil about Smalltalk ( ) but to me that looks like a formal method definition rather than an anonymous block.

Oh oops, the notation is different for lambdas? I see, it's supposed to remind you of the "such that" in set notation? I get it.

PS You know more about Smalltalk than I do! That's why it's all Jens's code. smile

EDIT: PPS: Congratulations!!! And demosthenes too!! Good thing this isn't like real-world elections, where the people I vote for always lose.

Last edited by bharvey (2010-10-22 12:25:58)

rubiks_cube_guy238 · 2010-10-22 18:13:05

Another glitch:
Edit the type of any input in any block, and then go to Edit menu -> Undelete.
The internal script for the block is attached to the cursor.

bharvey · 2010-10-22 18:20:04

rubiks_cube_guy238 wrote:
Another glitch:
Edit the type of any input in any block, and then go to Edit menu -> Undelete.
The internal script for the block is attached to the cursor.

How do you guys think to try these things??? hmm

Thanks. BTW, you can report bugs at http://byobugs.com

NOTE: If you are under the age of 13, please do not create an account, and log in with the username: "guest@byobugs.com" and the password: "password" (without the quotes) instead.

fullmoon · 2010-10-22 18:28:17

bharvey wrote:
EDIT: PPS: Congratulations!!! And demosthenes too!! Good thing this isn't like real-world elections, where the people I vote for always lose.

Hey bharvey,
Thanks for congratulating me. However, you should be aware that congratulations are offensive to some people. Please review the Terms of Use before doing something like that again in the future. Scratch On! big_smile

^ I'm practicing my "official voice" wink

I'm glad your candidate won for a change!

bharvey · 2010-10-22 18:33:45

fullmoon wrote:
congratulations are offensive to some people.

Oh. roll

^ I bet some people find that offensive too! smile

fullmoon · 2010-10-22 18:50:31

bharvey wrote:
fullmoon wrote:
congratulations are offensive to some people.
Oh.

^ I bet some people find that offensive too!

Looks like I should go review the Terms of Service.

bharvey · 2010-10-22 20:53:49

fullmoon wrote:
Looks like I should go review the Terms of Service.

No, no, my uparrow was pointing to the rolleyes, not to the quote from you. (It actually took me a while to understand your reply, since I knew what I meant.)

EDIT: The point being, if they interpreted the ToS that sensitively, they'd edit the repertoire of smileys!

Last edited by bharvey (2010-10-22 20:57:23)

fullmoon · 2010-10-22 20:59:12

bharvey wrote:
fullmoon wrote:
Looks like I should go review the Terms of Service.
No, no, my uparrow was pointing to the rolleyes, not to the quote from you. (It actually took me a while to understand your reply, since I knew what I meant.)

Ah! It's amazing how things can be misinterpreted through online communication.

bharvey · 2010-10-23 17:07:06

@shadow: Hey, if you're in Dallas 7pm Fri 3/11/11 you can help teach our workshop for teachers at the conference! smile

Jens · 2010-10-24 19:46:04

Good catch, fullmoon, and congratulations, too!

bharvey wrote:
Oh oops, the notation is different for lambdas? I see, it's supposed to remind you of the "such that" in set notation? I get it.

Don't worry, Brian, most Smalltalkers aren't even aware that there are things like formal parameters for lambdas in Smalltalk, because, funny thing is, most Smalltalkers don't ever declare lambdas themselves, instead we're mostly always using selectors of formally declared methods, as in

Code:

#(foo bar baz) do: [ :selector | 
    someObject perform: selector ]

because, you know, Smalltalk really is about sending messages to objects, and not about directly invoking object properties which just happen to be functions. smile (It's only by being exposed to weirdo functionalists that we become infiltrated by the dark side of the force big_smile )

Last edited by Jens (2010-10-24 19:46:44)

bharvey · 2010-10-24 20:35:24

Jens wrote:

Code:

#(foo bar baz) do: [ :selector | 
    someObject perform: selector ]

That's still a lambda with a formal parameter (selector)!

I wish there were a \mapsto symbol in ASCII (looks sort of like this: |-> a right arrow with a vertical bar at its tail), which is the correct symbol for putting formal parameters before an expression to make a function. Then I'd have understood it the first time. smile

Scratch

archived forums

#2026 2010-10-21 01:08:11

Re: BYOB 3 - Discussion Thread

fullmoon wrote:

Code:

#2027 2010-10-21 01:16:22

Re: BYOB 3 - Discussion Thread

fullmoon wrote:

#2028 2010-10-21 03:57:10

Re: BYOB 3 - Discussion Thread

fullmoon wrote:

#2029 2010-10-21 12:11:07

Re: BYOB 3 - Discussion Thread

#2030 2010-10-21 12:26:55

Re: BYOB 3 - Discussion Thread

fullmoon wrote:

#2031 2010-10-21 13:31:02

Re: BYOB 3 - Discussion Thread

Code:

Code:

#2032 2010-10-21 19:00:34

Re: BYOB 3 - Discussion Thread

#2033 2010-10-21 20:40:30

Re: BYOB 3 - Discussion Thread

fullmoon wrote:

Code:

Jens wrote:

#2034 2010-10-21 20:41:46

Re: BYOB 3 - Discussion Thread

ProgrammingFreak wrote:

#2035 2010-10-22 03:43:21

Re: BYOB 3 - Discussion Thread

bharvey wrote:

fullmoon wrote:

Code:

Jens wrote:

Code:

Code:

#2036 2010-10-22 04:32:02

Re: BYOB 3 - Discussion Thread

#2037 2010-10-22 09:59:22

Re: BYOB 3 - Discussion Thread

Jens wrote:

Code:

#2038 2010-10-22 10:03:17

Re: BYOB 3 - Discussion Thread

Guinea_Pig_Girl wrote:

#2039 2010-10-22 11:31:36

Re: BYOB 3 - Discussion Thread

bharvey wrote:

Jens wrote:

Code:

#2040 2010-10-22 11:54:01

Re: BYOB 3 - Discussion Thread

fullmoon wrote:

#2041 2010-10-22 18:13:05

Re: BYOB 3 - Discussion Thread

#2042 2010-10-22 18:20:04

Re: BYOB 3 - Discussion Thread

rubiks_cube_guy238 wrote:

#2043 2010-10-22 18:28:17

Re: BYOB 3 - Discussion Thread

bharvey wrote:

#2044 2010-10-22 18:33:45

Re: BYOB 3 - Discussion Thread

fullmoon wrote:

#2045 2010-10-22 18:50:31

Re: BYOB 3 - Discussion Thread

bharvey wrote:

fullmoon wrote:

#2046 2010-10-22 20:53:49

Re: BYOB 3 - Discussion Thread

fullmoon wrote:

#2047 2010-10-22 20:59:12

Re: BYOB 3 - Discussion Thread

bharvey wrote:

fullmoon wrote:

#2048 2010-10-23 17:07:06

Re: BYOB 3 - Discussion Thread