[HN Gopher] Snap is Scheme disguised as Scratch [pdf]
___________________________________________________________________
Snap is Scheme disguised as Scratch [pdf]
Author : juliangamble
Score : 81 points
Date : 2021-08-28 11:13 UTC (1 days ago)
(HTM) web link (people.eecs.berkeley.edu)
(TXT) w3m dump (people.eecs.berkeley.edu)
| delosrogers wrote:
| I first learned to program with Snap! and I really enjoyed
| learning recursion and other basic techniques with it.
| User23 wrote:
| > 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.
| spdegabrielle wrote:
| Snap is awesome! Kids learning HOP
| sitkack wrote:
| I love seeing the look in someone's eyes the first time they
| use a program to write a program.
| flafla2 wrote:
| 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...
| lucian1900 wrote:
| Unreal Engine Blueprints absolutely scale, if you've played any
| recent games you've seen them in action.
| disconcision wrote:
| > does not scale beyond the absolute basics
|
| doing precisely this is the subject of the paper though. i
| don't think they've fully succeeded either but it's worth
| engaging with. in principle there's nothing stopping a
| development environment which offers a smooth progression
| between drag and drop blocks and a fully featured language
| offering a typical text editor interaction experience.
| MarcScott wrote:
| > Block based programming absolutely has its place, but it does
| not scale beyond the absolute basics.
|
| A colleague of mine did last year's Advent of Code in Scratch.
| It's not a patronising language.
| Jare wrote:
| > 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.
| sitkack wrote:
| We should never introduce filters to education and
| understanding. It is immoral.
|
| Giving examples of tenacious kids battling their tooling is
| evidence that we should increase the slope of the difficulty
| curve. This isn't how pros train, this is how you self select
| for kids you don't have to teach.
| hjek wrote:
| Alright kindergarten, today we're gonna right ahead with
| calculus part II.
|
| Even if we "take the gloves off as soon as possible", there
| is a point at which Snap is brilliant. Are you going to
| teach Python to primary schoolers?
| sitkack wrote:
| I think we agree? Snap is brilliant and we should strive
| to teach everyone a subject, not just those that get-it
| on the first try. I _don 't_ think we should make things
| harder than they must be.
| flafla2 wrote:
| 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 :)
| throwaway47292 wrote:
| I can relate a bit, I think something is lost with scratch, it
| just seems fake and unreal.
|
| I tried it with my daughter(10) and she did not respond to it,
| of course it was likely my fault. After that I changed the
| approach to be more tangible, making apps, websites, roblox
| games, python games etc, and she is getting better and better.
|
| However the games 'human resource machine' and '7 billion
| humans' as visual programming were incredibly helpful.
| (tomorrowcorporation.com)
|
| I document the process here:
| https://github.com/jackdoe/programming-for-kids
| neilv wrote:
| 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.
| :)
| eatonphil wrote:
| 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.
| neilv wrote:
| 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.
| eatonphil wrote:
| 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.
| Zababa wrote:
| 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.
| diskzero wrote:
| The author states: _Prior to joining the Snap! project, I had
| spent 20 years teaching computer science using the best computer
| science book ever written, Structure and Interpretation of
| Computer Programs (SICP)._
|
| I have also taught high-school aged students using a modified
| version of SICP, Picturing Programs [1], and have had a very high
| success rate. The students have been able to comprehend topics
| like recursion and functional programming as a natural
| progression of learning. After completion of the course, they are
| able to pick up other languages like Javascript and Python
| rapidly, given the fundamentals they have learned.
|
| The question I have, which I could not find an answer for in the
| article, is why Snap, or any visual programming language, leads
| to greater successful outcomes than using SICP and Racket? Even
| if you agree that Scheme/Racket has limited practical value in
| the workplace, I have found that students who learned these
| languages have a much greater facility to learn other languages.
| Courses that I have taught using Javascript and Python have not
| given the students that same ability.
|
| Students who I have taught using Racket and SICP have a much
| deeper understanding of the fundamentals of computer science and
| they pick up these fundamentals in a much more organic way.
|
| [1] http://picturingprograms.com
| hjek wrote:
| > The question I have, which I could not find an answer for in
| the article, is why Snap, or any visual programming language,
| leads to greater successful outcomes than using SICP and
| Racket?
|
| Because you can't make syntax errors (as the blocks don't fit)
| or spelling mistakes (because you drag-and-drop the blocks).
| Racket is great but Snap can be accessible even to primary
| schoolers who're just getting into Scratch. Snap's emphasis on
| drawing on the canvas has a very Logo / Turtle Graphics feel to
| it, which DrRacket doesn't quite have.
|
| What makes it easier for the teacher is that Snap is in JS so
| you don't have to go through the app store to run it on school
| iPads (because that's just what's there in many classrooms,
| sadly). If the page is blocked on school wifi, you can even set
| up a local hotspot for it.
|
| I imagine it could be potentially be more difficult to get
| Racket running on school iOS? Don't Apple have a ban on apps
| that can run code in many instances?
| diskzero wrote:
| Apple will make exceptions for education apps that can
| execute code, but I think your observation is good about
| iPads/tablets in general. They are not great devices for
| keyboard-driven programming apps, unless you have a keyboard
| attached!
|
| You make a good point about syntax errors and the ergonomics
| of connecting blocks. My initial point was that Snap might
| not be the best option for high-school aged students. I can
| totally see it being really nice for younger students.
| Ericson2314 wrote:
| I have my doubts about the snap style of visual programming,
| e.g. due it emphasizing imperative code too much, but I have no
| doubt that text is bad. I've watched too many students struggle
| with text and the beginning, and this accident complexity slows
| down the learning by weeks.
| hjek wrote:
| > I have my doubts about the snap style of visual
| programming, e.g. due it emphasizing imperative code too
| much,
|
| The whole point of Snap is to encourage you to _" Build Your
| Own Blocks"_ which can call themselves recoursively. They've
| made it really seamless, whereas in Scratch you just got all
| these looping constructs and limited options for abstraction.
| There is nothing inherent in visual programming which
| emphasizes imperative code. You should really try it; just
| implementing a quick fibonacci or something.
| Ericson2314 wrote:
| I meant to say "scratch style", emphasizing the
| commonalities between them.
|
| For example, I would have no mutation or ;+like things at
| all in my teaching language. All edges would represent
| dataflow.
| Areading314 wrote:
| This is an exciting project but the visuals are so poorly
| designed that it makes my eyes hurt. I think bringing in some
| designers could lead to something really elegant here.
| kwhitefoot wrote:
| > 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.
| zozbot234 wrote:
| 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.)
| codetrotter wrote:
| I don't understand why Scheme would be any more suited for
| that than any other language exactly.
| disconcision wrote:
| using a lisp here simplifies things from implementation and
| interaction model perspectives. you already have a simple,
| canonical AST out of the box, which in-principle suffices
| to support the entire language, not just a toy version. so
| it makes sense lisps are attractive targets for getting
| something rolling in this space, though it's certainly
| debatable whether it's long-term the best choice.
|
| (my own efforts in this space (a structured editor in
| racket), which i was able to get going as a novice
| programmer: https://www.youtube.com/watch?v=CnbVCNIh1NA)
| benrbray wrote:
| Can you give an example of a language that does not have
| an AST?? Homoiconicity may be slightly more convenient
| but it is certainly not necessary.
| disconcision wrote:
| it depends what you mean by 'have'. any language in-
| principle probably has something describable as an AST
| but it's not necessarily something particularly well-
| specified. you can derive a CST from a presentation of
| the grammar, but it's not necessarily easy to work with
| in an editing context. in general, intermediary data
| structures are often left entirely to the discretion of
| the compiler implementer.
|
| likely various tree-like structures exist implicitly or
| explicitly during compilation, which may or may not be
| ideally suited for editing interactions. for example, if
| they are heavily nested with intermediary productions or
| discard surface style choices.
|
| sexps offer a simple (debatably too simple) shortcut
| here.
| elcomet wrote:
| Because it's a lisp, code is a data structure
| xscott wrote:
| 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.
| zozbot234 wrote:
| 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.
| xscott wrote:
| I agree with everything you said, and I still think it's a
| clever/useful idea for new programmers.
| wizzwizz4 wrote:
| > _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.)
| xscott wrote:
| 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.
| wizzwizz4 wrote:
| > _Blocks for cloud variables have a small square in
| front of them to distinguish them from regular variables,
| like this:_
|
| That's _supposed_ to be a cloud icon. :-p
___________________________________________________________________
(page generated 2021-08-29 23:01 UTC)