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

21–30 of 41 posts

Re: Snap is Scheme disguised as Scratch [pdf]

#21

Post by wizzwizz4 »

xscott wrote: post #16
wizzwizz4 wrote: post #13

Earlier quoted context omitted.

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

> 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

Re: Snap is Scheme disguised as Scratch [pdf]

#22

Post by disconcision »

flafla2 wrote: 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

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.

Re: Snap is Scheme disguised as Scratch [pdf]

#23

Post by throwaway47292 »

flafla2 wrote: 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…

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

Re: Snap is Scheme disguised as Scratch [pdf]

#24

Post by disconcision »

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.

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)

Re: Snap is Scheme disguised as Scratch [pdf]

#25

Post by benrbray »

disconcision wrote: post #24
codetrotter wrote: post #17

Earlier quoted context omitted.

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

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…

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.

Re: Snap is Scheme disguised as Scratch [pdf]

#26

Post by disconcision »

benrbray wrote: post #25
disconcision wrote: post #24

Earlier quoted context omitted.

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…

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.

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.

Re: Snap is Scheme disguised as Scratch [pdf]

#27

Post by MarcScott »

flafla2 wrote: 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…

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

Re: Snap is Scheme disguised as Scratch [pdf]

#28

Post by diskzero »

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

Post reply on HN