Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Snap is Scheme disguised as Scratch [pdf]

people.eecs.berkeley.edu

Post reply on HN
Print view View original

11–20 of 41 posts

Re: Snap is Scheme disguised as Scratch [pdf]

#11

Post by zozbot234 »

xscott wrote: post #10
kwhitefoot wrote: post #3

> then there’s no need to remember punctuation rules. The visual layout of the code is the notation. This is hardly a compelling reason to switch to a visual layout. One could just change the syntax rules to eliminate the semicolon and require new line or end of file instead. Then the code looks remarkably like the visual layout with the advantage that simple tools can search it and edit it.

I think maybe you're missing some subtlety here. In Scratch, the type of a parameter or expression is denoted by it's shape. Strings are square, numbers are round, booleans are angled, and statements are shaped like puzzle pieces. You don't need quotation marks and escape characters for strings. So new users can be oblivious to types for a little while - just tell them they can't put a square peg into a round hole. I…

The thing about shape is that it's a feature of visual syntax. A visual language where shapes are used to distinguish different primitive types is structurally no different from a toy BASIC where each type is given its own sigil character (!#$& etc.). We moved away from this use of sigils because it made it harder to abstract away from primitive types. I can see Snap! developers making the same choice.

Re: Snap is Scheme disguised as Scratch [pdf]

#12

Post by xscott »

zozbot234 wrote: post #11
xscott wrote: post #10

Earlier quoted context omitted.

I think maybe you're missing some subtlety here. In Scratch, the type of a parameter or expression is denoted by it's shape. Strings are square, numbers are round, booleans are angled, and statements are shaped like puzzle pieces. You don't need quotation marks and escape characters for strings. So new users can be oblivious to types for a little while - just tell them they can't put a square peg into a round hole. I…

The thing about shape is that it's a feature of visual syntax . A visual language where shapes are used to distinguish different primitive types is structurally no different from a toy BASIC where each type is given its own sigil character (!#$& etc.). We moved away from this use of sigils because it made it harder to abstract away from primitive types. I can see Snap! developers making the same choice.

I agree with everything you said, and I still think it's a clever/useful idea for new programmers.

Re: Snap is Scheme disguised as Scratch [pdf]

#13

Post by wizzwizz4 »

xscott wrote: post #10
kwhitefoot wrote: post #3

> then there’s no need to remember punctuation rules. The visual layout of the code is the notation. This is hardly a compelling reason to switch to a visual layout. One could just change the syntax rules to eliminate the semicolon and require new line or end of file instead. Then the code looks remarkably like the visual layout with the advantage that simple tools can search it and edit it.

I think maybe you're missing some subtlety here. In Scratch, the type of a parameter or expression is denoted by it's shape. Strings are square, numbers are round, booleans are angled, and statements are shaped like puzzle pieces. You don't need quotation marks and escape characters for strings. So new users can be oblivious to types for a little while - just tell them they can't put a square peg into a round hole. I…

> Strings are square, numbers are round,

All variables are round. The only thing that's square is a text input box. (The background colour, white, is the thing denoting that you can put any variable in the box.)

Re: Snap is Scheme disguised as Scratch [pdf]

#14

Post by eatonphil »

neilv wrote: post #5

Speaking only from a Scheme adoption perspective (which I don't think is the goal of the authors, but is relevant to some practitioners on HN)... One of the barriers to adoption that Scheme faced at a crucial point in time seemed to be that many people had seen Scheme in an intro CS class, and thought it was just an academic toy language. I don't think a Fisher Price makeover helps fix the "toy" optics. :)

I don't think this is really the case.

A quick search will show you a number of places Scheme is used in real software such as in gdb, gimp, etc. See also the work Cisco has supported in Chez Scheme.

I don't think it will ever be as popular as Ruby, Python or JavaScript but it's a very simple language to implement and use as a scripting language so I see it continuing to be a reasonable choice in some environments.

Re: Snap is Scheme disguised as Scratch [pdf]

#15

Post by User23 »

> These are three instructions to the computer, with semicolons in between. Now, what about that red semicolon at the end? If the language is Java, C, or C++, that semicolon is required. If it’s Perl, Pascal, or PL/I, that semicolon is forbidden. Not exactly easy to learn

In my mind the logical way to view this is that semantically some languages use ";" as a statement terminator:

  S1; S2;
This is executing S1 followed by S2. In this case ";" is purely syntactic, it has no semantic meaning beyond telling the interpreter/compiler where a statement's procedure text ends.

The other way is using ";" as a statement compositor:

  S1; S2
This is defining a single compound statement whose semantics are the same as executing S1 followed by S2. In this case ";" has semantic meaning.

Of course, practically speaking most languages kind of just conflate the two. For example the first way could have syntactic sugar allowing the final statement terminator to be elided. Similarly, the second way could have a trailing ";" and it could just mean compose on a NoOp. And when it comes to actually executing the code both will probably run very similar processes. But I personally find the latter conceptual framework more aesthetically pleasing.

It looks like the Snap developers share my view that semantics is way more interesting than syntax.

Re: Snap is Scheme disguised as Scratch [pdf]

#16

Post by xscott »

wizzwizz4 wrote: post #13
xscott wrote: post #10

Earlier quoted context omitted.

I think maybe you're missing some subtlety here. In Scratch, the type of a parameter or expression is denoted by it's shape. Strings are square, numbers are round, booleans are angled, and statements are shaped like puzzle pieces. You don't need quotation marks and escape characters for strings. So new users can be oblivious to types for a little while - just tell them they can't put a square peg into a round hole. I…

> Strings are square, numbers are round, All variables are round. The only thing that's square is a text input box. (The background colour, white, is the thing denoting that you can put any variable in the box.)

If we're being pedantic, I should've used the word "parameter" instead of "variable", but surely you know what I meant. If not, see the "What's in a shape?" section of

https://nostarch.com/download/samples/Learn-Scratch-05.pdf

It starts at the bottom of page 92.

Re: Snap is Scheme disguised as Scratch [pdf]

#17

Post by codetrotter »

zozbot234 wrote: post #9
kwhitefoot wrote: post #3

> then there’s no need to remember punctuation rules. The visual layout of the code is the notation. This is hardly a compelling reason to switch to a visual layout. One could just change the syntax rules to eliminate the semicolon and require new line or end of file instead. Then the code looks remarkably like the visual layout with the advantage that simple tools can search it and edit it.

The nice thing about a language like Scheme is that it can potentially support both views seamlessly. Just add it as a rendering option to your IDE, and use it when appropriate - perhaps for coding on a non-standard interface such as a touchscreen, where this kind of input might be preferred. (Of course the flip side is that any Snap program can also have an isomorphic Scheme representation, for easy editing with a k…

I don’t understand why Scheme would be any more suited for that than any other language exactly.

Re: Snap is Scheme disguised as Scratch [pdf]

#18

Post by elcomet »

codetrotter wrote: post #17
zozbot234 wrote: post #9

Earlier quoted context omitted.

The nice thing about a language like Scheme is that it can potentially support both views seamlessly. Just add it as a rendering option to your IDE, and use it when appropriate - perhaps for coding on a non-standard interface such as a touchscreen, where this kind of input might be preferred. (Of course the flip side is that any Snap program can also have an isomorphic Scheme representation, for easy editing with a k…

I don’t understand why Scheme would be any more suited for that than any other language exactly.

Because it's a lisp, code is a data structure

Re: Snap is Scheme disguised as Scratch [pdf]

#19

Post by neilv »

eatonphil wrote: post #14
neilv wrote: post #5

Speaking only from a Scheme adoption perspective (which I don't think is the goal of the authors, but is relevant to some practitioners on HN)... One of the barriers to adoption that Scheme faced at a crucial point in time seemed to be that many people had seen Scheme in an intro CS class, and thought it was just an academic toy language. I don't think a Fisher Price makeover helps fix the "toy" optics. :)

I don't think this is really the case. A quick search will show you a number of places Scheme is used in real software such as in gdb, gimp, etc. See also the work Cisco has supported in Chez Scheme. I don't think it will ever be as popular as Ruby, Python or JavaScript but it's a very simple language to implement and use as a scripting language so I see it continuing to be a reasonable choice in some environments.

Scheme is suited for more than just a scripting language. Production-grade implementations are difficult rather than easy. We've mostly failed at adoption that arguably was merited, including for the reason I mentioned.

One sign of the failure became that, for years and years, advocates kept trotting out the same handful of adoption examples. Those examples started to get stale, and at some point sounded out of touch or desperate, like bragging about how we got on the junior varsity team in high school, still mentioning that well after high school. I worked on one of the relatively big success stories, and even I've given up on mentioning that example in most circumstances.

BTW, Chez is great, and it's now being used for the Racket backend.

Re: Snap is Scheme disguised as Scratch [pdf]

#20

Post by eatonphil »

neilv wrote: post #19
eatonphil wrote: post #14

Earlier quoted context omitted.

I don't think this is really the case. A quick search will show you a number of places Scheme is used in real software such as in gdb, gimp, etc. See also the work Cisco has supported in Chez Scheme. I don't think it will ever be as popular as Ruby, Python or JavaScript but it's a very simple language to implement and use as a scripting language so I see it continuing to be a reasonable choice in some environments.

Scheme is suited for more than just a scripting language. Production-grade implementations are difficult rather than easy. We've mostly failed at adoption that arguably was merited, including for the reason I mentioned. One sign of the failure became that, for years and years, advocates kept trotting out the same handful of adoption examples. Those examples started to get stale, and at some point sounded out of touch…

No disagreement about production-grade implementations, but most of the actual examples of use are proprietary and aging (exactly as you say). Whereas embedded Scheme just happens more frequently in major OSS so I find it less embarrassing to bring up, as you say.
Post reply on HN