Scratch already allows you to create custom Blocks and features lists. This seems like a perfect example of reinventing the wheel (and fragmenting development communities).
Actually there is a large historical overlap between the two communities -- warm, collaborative, always giving credit where due. Different goals, lots of feedback both ways.
Jens Mönig was on the Scratch Team (invited by Mitch Resnick). BYOB was presented at Scratch@MIT 2010 explicitly to merge ideas back into Scratch, not to fork the community:
Scratch => Snap!: browser rewrite timing influenced by Scratch 2.0 plans; Morphic via John Maloney; CC-licensed costumes/sounds used under license.
Shared people: Jens (Scratch Team => Snap! lead), John Maloney (Scratch/Morphic; GP session with Jens at Scratch2015AMS), Bernat Romagosa (Snap!, MicroBlocks, Snap4Arduino -- Bordeaux, Snap!Cons).
When I looked at Scratch six months ago, its lists were deliberately handicapped in function. They could only contain text or numbers; they could not contain other lists. Nor could they be passed as parameters to functions (!!), which really made me say "Nope, this is not what I'm going to use to teach programming to kids". I looked at Logo, and was drawing up lesson plans when I noticed Brian Harvey (the primary designer of Berkeley Logo which I was planning to use) had a lot of activity on this other repo. What in the world is https://github.com/jmoenig/Snap/ and why is Brian Harvey contributing to it so much? (Looks it up). Oh. OH.
And so I taught my class using Snap!, because it has:
- Lists that are proper first-class types, and can contain anything, including other lists, and also blocks
- Blocks (functions) that are also proper first-class types, and can take anything as parameters, including lists and blocks.
- Blocks that can create and return other blocks, thereby enabling functional programming
- All the standard list-handling primitives you would expect, like `filter` and `map`
All of which was missing from Scratch when I looked at it six months ago.
Scratch is a toy language, with a deliberate ceiling that you can't get past because of the language's design. Snap! is a real programming language with no ceiling, with the visual appearance of a toy. It takes longer to do anything in Snap! than in a professional language like Lisp or C# or Go or ... well, all of them, because dragging blocks together is a lot slower than typing. But you can do anything you need to in Snap!. There is no artificial limit that blocks you from going farther, the way Scratch has.
P.S. Saying that Scratch is artificially limited is not meant as a dig against the language. It's a deliberate design choice, and it's a fine choice if your intent is to teach people the very basics and then graduate them to another language. It's a choice I disagree with, because I prefer the way Snap! has implemented the same pedagogical choice (you can create tutorials with a limited set of blocks, to avoid presenting complete beginners with an overwhelming array of choices). But it's a defensible choice in many cases (many kids taking a programming class will not have the aptitude — and those who do turn out to have the knack for it can be graduated to Snap! really easily and not have to relearn everything).
Comments
Scratch already allows you to create custom Blocks and features lists. This seems like a perfect example of reinventing the wheel (and fragmenting development communities).
Snap implemented these features and others long before Scratch had. To my memory it might have been a decade earlier.
Actually there is a large historical overlap between the two communities -- warm, collaborative, always giving credit where due. Different goals, lots of feedback both ways.
Jens Mönig was on the Scratch Team (invited by Mitch Resnick). BYOB was presented at Scratch@MIT 2010 explicitly to merge ideas back into Scratch, not to fork the community:
https://scratched.gse.harvard.edu/resources/announcing-byob2...
Berkeley has kept showing up at Scratch conferences (Amsterdam 2015, Bordeaux 2017), and the Scratch forums hosted BYOB/Snap! discussion for years:
https://scratch.mit.edu/discuss/topic/4455/
So "NIH syndrome," "reinventing the wheel," and "fragmenting the community" is pretty much the opposite of how these two actually interact.
Documented cross-pollination:
BYOB => Scratch: custom blocks (Scratch 2.0 took command blocks only, not reporters/lambda). That was an explicit goal:
https://en.scratch-wiki.info/wiki/Snap!
Scratch => Snap!: browser rewrite timing influenced by Scratch 2.0 plans; Morphic via John Maloney; CC-licensed costumes/sounds used under license.
Shared people: Jens (Scratch Team => Snap! lead), John Maloney (Scratch/Morphic; GP session with Jens at Scratch2015AMS), Bernat Romagosa (Snap!, MicroBlocks, Snap4Arduino -- Bordeaux, Snap!Cons).
When I looked at Scratch six months ago, its lists were deliberately handicapped in function. They could only contain text or numbers; they could not contain other lists. Nor could they be passed as parameters to functions (!!), which really made me say "Nope, this is not what I'm going to use to teach programming to kids". I looked at Logo, and was drawing up lesson plans when I noticed Brian Harvey (the primary designer of Berkeley Logo which I was planning to use) had a lot of activity on this other repo. What in the world is https://github.com/jmoenig/Snap/ and why is Brian Harvey contributing to it so much? (Looks it up). Oh. OH.
And so I taught my class using Snap!, because it has:
- Lists that are proper first-class types, and can contain anything, including other lists, and also blocks
- Blocks (functions) that are also proper first-class types, and can take anything as parameters, including lists and blocks.
- Blocks that can create and return other blocks, thereby enabling functional programming
- All the standard list-handling primitives you would expect, like `filter` and `map`
All of which was missing from Scratch when I looked at it six months ago.
Scratch is a toy language, with a deliberate ceiling that you can't get past because of the language's design. Snap! is a real programming language with no ceiling, with the visual appearance of a toy. It takes longer to do anything in Snap! than in a professional language like Lisp or C# or Go or ... well, all of them, because dragging blocks together is a lot slower than typing. But you can do anything you need to in Snap!. There is no artificial limit that blocks you from going farther, the way Scratch has.
P.S. Saying that Scratch is artificially limited is not meant as a dig against the language. It's a deliberate design choice, and it's a fine choice if your intent is to teach people the very basics and then graduate them to another language. It's a choice I disagree with, because I prefer the way Snap! has implemented the same pedagogical choice (you can create tutorials with a limited set of blocks, to avoid presenting complete beginners with an overwhelming array of choices). But it's a defensible choice in many cases (many kids taking a programming class will not have the aptitude — and those who do turn out to have the knack for it can be graduated to Snap! really easily and not have to relearn everything).
Not to mention first class continuations! :)
Thanks!
Oh yeah, forgot about those! (I didn't teach them to beginners for obvious reasons). Those make it a Scheme rather than a Lisp.
And thank you for all your work not just on Snap!, but on Logo before that. You have done a lot for coding education.