Live data from Hacker News

Snap is Scheme disguised as Scratch [pdf]

people.eecs.berkeley.edu

1–10 of 41 posts

Re: Snap is Scheme disguised as Scratch [pdf]

#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.

Re: Snap is Scheme disguised as Scratch [pdf]

#4
The enormous effort to bring kids/young adults into CS is really awesome and admirable. However I fundamentally disagree with the philosophy of this paper. IMO, we should try to take the kid gloves off of our programming education as soon as possible.

I learned how to code when I was an adolescent (10-12). I wasn’t personally interested in the act of programming itself, but I was fascinated by the possibilities of what I could create with code. My first coding venture was in LEGO mindstorms block-based code, and this was great to introduce fundamental concepts like loops and boolean logic. But I didn’t care about any of that until much later, I just wanted to build a LEGO gun so I could shoot pegs at my brother (hah!).

Soon enough my interests wandered (as would any kid’s), and I wanted to make a mod for Minecraft. At the time this involved decompiling the java source code, modifying the java code with the changes, and recompiling it back to bytecode. That’s right, I installed eclipse at the age of 12. I shudder at the memory.

But you know what? I didn’t care, because I was passionate about what I wanted to create. There were tutorials and tools online to help me with the mundane bits. The OP article opens by claiming that their language is better for learning because it doesn’t have gotcha’s like semicolons… but that was absurdly easy to figure out (just pattern match with the other code you see!). All it took was a drive to figure it all out. And in the end my mod (which is still available online! see [1]) shipped to tens of thousands of players. Until recently it was the most successful project I was ever involved with.

Now, I don’t mean to suggest that every kid should have to deal with arcane build systems and linker hell (that would be sadistic). But my point is that kids are willing to put up with a whole lot of BS in order to create.

I’ve taught summer coding and 3D art classes to adolescents myself, and I’ve verified this personally:

- I’ve seen a 10 year old fiddle with obscure configuration options in the Unity game engine that would confuse a trained artist, just so they could see their stuffed animal in VR.

- I’ve seen a 12 year old download Autodesk Inventor fusion on his home PC so that he can make a 3D model of a lightsaber.

- I’ve had a kid stay hours after class so they can fiddle with a C# script that I provided to them for a game dev assignment — just so they can execute on their vision.

I haven’t seen this kind of success with block based programming. Because the whole language is on rails, you tend to get half-assed results that follow whatever tutorial I supply by the letter. Results are bounded by the bespoke language features that are provided (eg sprites) so kids may not feel that they can achieve exactly what they want. It completely kills the creative freedom that a kid craves.

Block based programming absolutely has its place, but it does not scale beyond the absolute basics. Kids don’t want to be patronized with a training wheel language and we should give them the opportunity to push through the tricky parts of a “big boy/girl” language if they are inclined.

[1] https://www.minecraftforum.net/forums/mapping-and-modding-ja...

Re: Snap is Scheme disguised as Scratch [pdf]

#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. :)

Re: Snap is Scheme disguised as Scratch [pdf]

#6
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. :)

That's a good point. I had my first semester in Scheme, and while it was fun, the biggest project was a Sudoku solver with the sudoku directly in the program. We didn't even do file IO. On the other hand, we studied functional programming with Javascript while using it to build a webpage, something that was concrete. We learned domain and tuple relational calculus with SQL and PHP, and built a small website, again something concrete. We had the choice between logical and graphics programming. I took logical, where we did some Prolog, and solved a few enigmas with it. In the graphics programming, people used C++ with a library and made a cool 3D scene with trees, a river and a few objects.

All of that was made without libraries (except for the C++ graphics stuff), so the usual "ecosystem problem" that plague small languages compared to the big ones wasn't even a problem here. But I still finished college with a clear divide between "language you use for work" and "language you use for research probably?". That was before knowing about package managment, frameworks and ecosystems. It's hard to not be biased after that.

Re: Snap is Scheme disguised as Scratch [pdf]

#7
post #4

The enormous effort to bring kids/young adults into CS is really awesome and admirable. However I fundamentally disagree with the philosophy of this paper. IMO, we should try to take the kid gloves off of our programming education as soon as possible . I learned how to code when I was an adolescent (10-12). I wasn’t personally interested in the act of programming itself, but I was fascinated by the possibilities of w…

> does not scale beyond the absolute basics

> if they are inclined

I agree with those, but I want to emphasize how important it is to ensure that the "absolute basics" remain accessible to the least inclined until they discover if they want to scale up to the next level or not.

In regular shared classroom education, one of the toughest elements of accessibility is to ensure nobody ends up left out because of unfavorably comparing themselves to the stars of the subject. I myself was a star in computers, but a total and abject "I don't want to be here" failure in physical education - I remember how it feels on both ends.

Re: Snap is Scheme disguised as Scratch [pdf]

#8
post #7
post #4

The enormous effort to bring kids/young adults into CS is really awesome and admirable. However I fundamentally disagree with the philosophy of this paper. IMO, we should try to take the kid gloves off of our programming education as soon as possible . I learned how to code when I was an adolescent (10-12). I wasn’t personally interested in the act of programming itself, but I was fascinated by the possibilities of w…

> does not scale beyond the absolute basics > if they are inclined I agree with those, but I want to emphasize how important it is to ensure that the "absolute basics" remain accessible to the least inclined until they discover if they want to scale up to the next level or not. In regular shared classroom education, one of the toughest elements of accessibility is to ensure nobody ends up left out because of unfavora…

I’m glad you brought this up and I totally agree. Indeed, in a “learning language,” the basic things should be easy and approachable for beginners, but the hard things should be as easy as they can be as well. Or at the very least, hard things should be possible.

The best learning language that I’ve come across is Python. Nothing is harder than it needs to be at the beginner/intermediate level. And it scales all the way up to real work in the industry. Plus, the author of the OP would be happy to know that semicolons are not an issue :)

Re: Snap is Scheme disguised as Scratch [pdf]

#9

> 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 keyboard and mouse.)

Re: Snap is Scheme disguised as Scratch [pdf]

#10

> 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 think it falls apart pretty quickly as they add more features in Snap. For instance, are lists always lists of strings? And list themselves are rounded rectangles? Sprites and procedures are rounded rectangles? I guess they ran out of easily distinguished shapes, but maybe that's ok by the time new programmers start needing these features.

Post reply on HN