Kids don't need tools for kids
lambdaway.free.fr
lambdaway.free.fr
But it did lead to me learning C++, DirectX, OpenGL, 3d math, and so on. And I did end up in a place where I'm more or less paid to do what I did for fun back then.
Also, the learning process taught me frustration tolerance, which is a very useful skill to have in the industry, and which many others seem to lack.
Right now in the room next to me my son, who is five, is playing with Nintendo's Game Builder Garage. He likes watching me work, he likes using the Game Builder with me to make his own silly games together. And he spends a lot of time goofing off and making his own silly prototypes that don't amount to anything but give him a lot of pleasure. He's also very much into Minecraft and makes some astonishing things in Creative Mode which I didn't think you could (a city on land but encased in flowing water yet dry on the inside?!).
He's at an age where he loves creating and he has a surprising attention span for his age. I showed him code because he asked what it was, but he can't read yet. I've tried showing him actual game development tools since he said he wanted to learn. Despite being very smart and intensely focused that kind of exercise doesn't quite work for him, yet.
You made it through. Many kids don't. I too wanted the "real" stuff, but so much so I didn't embrace the medium I had before me. One could make Battle Zone in Logo or Flappy Bird in QBasic.
I'm really glad that kids today can build games with real-world professional tools that are much more friendly, like Unity or Godot.
Different strokes for different folks. Some find the distance between the fundamentals and a working demo extremely frustrating in a lower-level API.
- Helping kids think in new ways
- Building skills for "the future" / "jobs"
- Encouraging kids to create their own things, instead of just consuming
- Probably some others I'm not thinking about! (e.g. improving odds of getting into an "elite" college)
Each tool, whether it's C or Scratch, should be evaluated against the design goals as well as the embedded context / environment that children are introduced to programming in. This is a rich topic undoubtedly.
My 2 favorite starting resources are:
- Learnable Programming by Bret Victor: http://worrydream.com/LearnableProgramming/
- Mindstorms by Seymour Papert: https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...
The notion that there are visual learners etc. now doesn't seem to true (and possibly even a bit of a scam). But different approaches do appeal to different people and like any subject, teachers and students need to work together to find the ones that fit.
- Building skills for "the future" / "jobs" (what politicians promise)
- Encouraging kids to create their own things, instead of just consuming (what I want)
- improving odds of getting into an "elite" college (what the parents want)
- Encouraging parents to buy very overpriced toys
Different people learn differently, if a tool or method doesn't work for someone that's on them to find another tool or method.
Scratch for example is great for visual learners who haven't mastered what it is there to teach. It will work for some, not for others.
I’m always a bit wary of folks who just “get it” telling everyone about how they should or should not learn something. I remember a teacher who in my first programming class read from a book about C, and told us to now go complete a task. He wanted everyone to understand ALL the details for every line of code as we wrote it.
Took me 20 years before I seriously tried coding again.
[0] https://duckduckgo.com/?t=ffcm&q=Klik+And+Play&iax=images&ia...
Afterward I was able to get back to text coding and make a career of it.
I think I will have the same translation dilema if I start with scratch. At some point we will need to get writing textual based code but I am not confident that I can get my kids exited about programming without graphical tools like scratch/dragonbox.
In classroom setting most teachers could not teach the textual form of programming but something like scratch allows kids to explore and build the vocabulary to be able to translate to a textual representation.
I don't think the model language taught in the linked article is going to work for most kids, because the level of abstraction is too high. I'd guess that even most non-CS undergraduates would struggle with the double recursion implementation of Towers of Hanoi that he presents (even with the comments he also adds; without the comments I'd venture most non-CS undergrads would have serious trouble figuring it out).
Syntax and other errors in many language are also really frustrating and I've seen children give up on text-based languages in frustration with all the errors they get (especially when they make lots of typing mistakes!)
For example initially the unknown variable is the namesake cute dragon in a box, but it later becomes "x", the bubbles become brackets, the green whirlpool becomes 0, the cute animals become other variables etc.
Scratch itself has no concept of "custom reporters" - i.e. functions that return a value. If you want a function to return something, the closest approximation is to assign the result to a global variable. But you can't do recursion like that, so you'd need to use a "List" variable to emulate a stack.
If you wanted to write a recursive factorial function in "pure" Scratch, it would be significantly more convoluted than the one shown. Scratch cannot elegantly express the concept of recursion, so if you want to teach it, you probably shouldn't be using Scratch to do so.
I suppose this means I agree with the author in general, but I do think that Scratch is great for teaching the concepts that it can express well - i.e. very basic imperative programming, with sprite-based graphics.
[1] https://snap.berkeley.edu/
[2] https://cseducators.stackexchange.com/questions/112/what-can...
They over-focus on the onboarding and initial experience, but then forget to provide an escape hatch into more powerful concepts and methods (that all already exist!).
IMHO, we'd do kids a better service by just wrapping adult tools with "first steps" guidance, and then allowing them to click through to the full mode + additional docs when they're ready.
I don't see the lack of escape hatch as a weakness. It just gives you a stronger motivation to move on to a "real" language, when the time is right.
I don't think you can really wrap adult tools into something nearly as ergonomic as Scratch. Bear in mind that you don't need to be able to read, write, or type, to use scratch (although basic reading ability certainly helps).
I am certainly an outlier here, but I enjoy implementing advanced concepts in Scratch, for the challenge of working in such a constrained environment - I suppose in a similar way to how demoscene coders still enjoy working with the C64. For example, I recently implemented X25519 elliptic curve scalar multiplication in scratch[1] (I'm slowly working my way through most of libsodium's cryptographic primitives). It's a turing complete language, so there's really no limit to what you can do with it.
As an adult, progamming by dragging blocks around feels like wading through treacle, so I wrote some codegen tools in python to speed things up.
To enunciate my issue more clearly, I'd phrase it more as "Turing efficiency." I.e. "How cleanly and concisely can I implement an arbitrary advanced concept in a language/tool?"
If you have to construct a Rube Goldberg machine from the primitives afforded... that's interesting (in an Incredible Machine kind of way) but probably not ideally educating.
I certainly wouldn't want to have to support similarly architected code in production! ;)
And I think it isn't always clear to kids that "clever hacks" picked up over years of experimenting aren't the same as "good code" in more powerful languages. By that point, some of "well, that's what coding is" has been internalized.
With this language they can... implement functions like reverse, append and length by themselves?
I don't mind people exploring options, but please don't insult Scratch, then make up something for kids which (as far as I can tell) has never been shown to a kid.
So good, concise, contextual documentation with plenty of examples for anything kid touches.
So like Delphi F1 or PHP online docs.
Scratch doesn't have anything like that I think.
Many tools for kids don't give the kid ability to learn without direct adult instruction or watching long tutorial on something that's not the thing the kid wants to do at the moment.
However, the real strength of Scratch is that it doesn't need any documentation or instruction. A sufficiently curious mind can learn it simply by clicking around and trying things out. The blocks only click together in valid combinations (which you can infer from the shape of the blocks), so it's literally impossible to create a syntax error.
Everything needs documentation for a kid. Even a fork or a spoon.
Without ample examples of what you can do with the things you are just touching you make way slower progress and require much more motivation.
If it's human friendly and kid friendly with examples, pictures and heck, even a draggable blocks you can drag into your project kids would be all over it. Because it would be contextual. Pertaining to the thing they try to understand at the moment.
Scratch is not designed for a lonely bored kid. It's designed for a kid in the classroom following instructions.
Have enough modules available they can start making stuff they want to actually use. Help them find opportunities to solve problems that matter to them using code.
Your average kid would much prefer to write a Twitter bot than a car parts inventory system or calendar app. (The latter being a typical CS assignment)
The beauty of scratch is that it makes most syntax errors impossible to construct in the tool and provides immediate feedback on how far away the program is from being an acceptable program. Only recently have the tools I use regularly as a professional started to adopt that approach.
How much time has our industry lost in change / compile / error / change cycles? How much in typo-chasing because most languages are represented as strings, not things?
I think Scratch points the way to what professional tooling could be. It lacks polish, there's a lot of accelerators that would need to be added before it could match the development speed of typing lines and lines of text... But there's meat on those bones for an intrepid researcher to pursue.
{{lambda {:a :b}
bla bla bla :b :a bla bla bla}
hello world}
{{lambda {:a :b}
bla bla bla :b :a bla bla bla}
hello world}I like Scratch for kids for very small programs, and perhaps for programs with some easy to encapsulate subparts, but my feeling is that once you need to use recursion the friendly part of Scratch is a problem. My daughter used it for a month or two, but she preferred to go back to a language with text representation that makes cut&paste easy.
About the rest of the article: Does the compiler use some trick to make arithmetic operations faster under the hood or you are using just the unary/binary representation in lists?
I think you're missing the major point of scratch. The main obstacle in learning to program for an 8-year-old is not going to be learning the concepts, which are no harder for them than anyone else I think, but the typing is a problem. How many times have any of us (especially early in our programming development) gotten hung up on misspelled variable names? There's no inherent advantage to typing every keyword vs dragging blocks.
Additionally, the scratch ecosystem is designed around creating games and animations. As it turns out, young kids like games and animations, and it's a very rewarding experience to make something that you actually want to share with your friends and family. Even if your language is a better choice for a child that age, which I kind of doubt it is, it doesn't matter if the kids aren't interested in what they're making.
Again, I think your language looks great. Just not sure it's good for the same target market as scratch.
I was already touch-typing fairly proficiently at age 8, in the 80s, and I'm visually impaired as well. I started learning to program in Applesoft BASIC shortly after I turned 8, and the typing was never a barrier.
Edit: The teacher of the visually impaired who taught me to touch-type when I was 7 might have been unusually forward-thinking, but still, my experience shows what's possible. I hope the next generation of kids all learn to touch-type just as early.
In 2022, most computers kids use don't have keyboards anymore. Only onscreen low-speed ones.
There's meat on the bones of alternatives to keyboards in programming. It may not be possible to beat the data-entry speed of a keyboard, but it's worth remembering that the "mess around" computer kids have access to these days probably doesn't have one.
Maybe it's time I got my nieces and nephew Chromebooks for Christmas. By then, the youngest will be between 4 and 5 years old.
Just like how using Scratch is like (well is) playing a game.
Coming at children's learning from an adult perspective often isn't that useful. They just don't think like us a lot of the time.
Edit: So yeah, my anecdote is unique and probably worth nothing in this discussion.
Scratch being embedded in an environment with graphics and sound provides motivation, reward and problems to solve that are relatable and interesting to many children e.g. "how do I get the monkey to chase the rabbit".
The block "affordances" mean kids can get to the part where they make things without needing to learn any formal syntax. A lot of young children who are not ready to reason about syntax can nonetheless handle the ideas of events, conditionals etc.
Many young children have difficulty with the motor control required to use a mouse (mostly mitigated on tablets / touch screens). However, many adults also underestimate is how much "implicit" knowledge is involved in using a text editor.
I think anyone who tries to teach something "new" to kids will understand the experience of having it not go as planned.
Scratch looks weird partly because it's the result of people doing actual "user testing" with kids.
And if the output is also graphical, much easier to write simple games
Where Scratch shines is in the removal of frustrations. Rather than dealing with broken programs due to a misspelled variable, misplaced parenthesis, or syntax errors the learner has the opportunity to focus upon how the program works. That is far more valuable in the early stages.
TFA's experience mirrors my own: when I started programming, people kept trying to get me to use tools that promised to make my life easier (basic, logo, apple script). Without exception, they made my life harder, because their gimmick added less value than their lack of "production grade" polish took away. C was a breath of fresh air -- not because I had a fetish for segfaults and the clockwise spiral rule, but because good APIs and documentation and examples and debuggers were available, and that was much more important.
Today the situation is reversed: I primarily code in python which has sugary syntax, doesn't enforce types, has poor debug/profiling/ui tooling, and still struggles with multithreading 20 years after the death of Dennard scaling. However, it's the lingua franca of the ML/AI space, and that matters more to me than all of its many shortcomings put together.
Ecosystem > language. Every time. It's true for kids, it's true for adults, and I bet it's true for space aliens, too.
Another high point of Scratch is that it includes message passing and concurrency. This allows for telling complicated stories, and it also introduces some very hard to track bugs -- so, kids learn some debugging as well.
Recursion would be comparatively easy; you could even teach linear logic by endowing your "characters" with an inventory of objects that they could pass on to each other and transform by acting on them, a common trope in adventure games.
Formatting tools with a standard default syntax solve that problem quite nicely, and they do it more effectively than something as error-prone as significant whitespace.
I would have found something dumbed down and kid specific uninteresting, the thing about QBasic that kept me interested was: included example games (gorillas and nibbles) whose code you could see and modify (I've had much laughs by changing radiuses of circles of how the gorillas were drawn), the ability to draw graphics (which is an interesting form of feedback to your code), the excellent documentation and ease of use (integrated good help text of every function and keyword), and the fact that you could use it to make anything including useful software which gave a good reason to want to learn it
I'd have seen something like logo with a turtle that moves around as a game instead of a tool, that would have kept me interested for maybe a few days max
No one likes the idea of something "dumbed down", but Scratch and block languages generally are not dumbed down, they're just visually different. It's all the same stuff, but a visual instead of text representation.
> QBasic that kept me interested was: included example games (gorillas and nibbles)
Yes, this is what many block based languages provide, examples, and also a thriving online community.
I read the author as saying "I like playing around with things. I didn't like playing around with 'kiddy' things when I was younger, so I made a simple playful programming language that's not 'kiddy'".
I read the page and thought it was a fun language. I'm not sure I could do a good job of using it to teach a class of young people, but I'm sure there are some out there who would get a kick out of it.
In the 90s, computers needed programs to be useful, and regular computer users needed to be able to make them (not so much as the 80s but it was still around). I saw my elders creating software in the HyperCards and Visual Basics of the day, and thought "Hey, I want to do that" so I did.
They were both tools to get Real Work Done™ AND be approachable to non-programmers. Thus, I didn't feel limited by the stuff that's for children, but they were still friendly enough to be approachable from zero knowledge + maybe a book from the library.
Children's tools tend to only have the approachable part, which is good, but as a kid /knowing/ that anything a "real" program could do was possible with the tool I had if I just tried hard enough was a huge motivating factor in eventually bootstrapping my learning.
I was using Turbo Pascal when I was 11. Many children are way more interested in "adult" conversations and tools than educators give them credit for.
> I was using Turbo Pascal when I was 11.
Ignoring the fact that the whole stack was way much easier back in the day (I was a Turbo Pascal user as well at more or less your age), to me it's also a pretty clear case of survivorship bias. There will be kids that will find their way into no matter what, but we should also give tools/resources to help other kids without the same level of interest+capabilities to at least scratch the surface.
I also know a bunch of smart guys who dropped out of comp sci at Uni because that's what they were taught in their first semester. Some of them became developers anyway, others decided that they would never learn to code and did other things instead (which is fine, of course, but I'm sure they could've learned Python first and moved on to SML later).
Tools like Scratch aren't meant to be anyone's daily driver, they're meant to give people a taste of the power of code without having to be bogged down in all of the complexity.
I was fortunate enough to participate in some day camps about a decade ago designed to get girls interested in STEM. The participants were primarily Girl Scout Brownie troops (pre-K and K) and the camp consisted of 6 different modules. The camp was a half day long and the girls would complete all 6 modules, so about 30 minutes each.
One of the modules was setup by a team from Georgia Tech and in it the girls were asked to create a robot to play soccer either as a goalie or a kicker using Lego WeDo sets, and then program the software to control it in Scratch.
Without knowing the background of or having the time to individually coach each child, in 30 minutes two undergrads were able to teach a dozen 6-9 year old kids rudimentary robotics and software development. Each group was able to build a functional robot.
But I know many programmers that started with tools like RPGMaker and Scratch instead. I think it has much more to do with the individual child's interests and learning style.
Scratch is actually harder.
Scratch relies on making sense of these big blocks with little blocks and these UI patterns that don't make sense and aren't seen elsewhere. It relies on finding blocks from a palette.
Something like QuickBasic or TurboPascal or Wiring (Arduino) doesn't. You write the program from top to bottom using magic words (syntax) and you press f5 and the computer follows the incantation.
That 'easier to parse syntax' of yours might actually be trickier for other minds to work with, where they instead benefit from big blocks, little blocks and coloured abstractions that might be like so much fluff to you.
No way of learning or comprehending makes 5+ discrete tasks easier than 1. There is no mental model that changes the actual bitrate flow of comprehension.
Yes, visual learners are a thing. No, visual learners do not prefer doing more work nor does it help them learn "faster". Recognizing and discriminating colors/shapes/sizes is always more work (and more abstraction! "Blue blocks are conditional statements" is learned behavior!)
We didn't make programming visual. We replaced text entry with a bad UI paradigm.
If you want to see visual programming, go look at SpaceChem or Opus Magnum.
[video warning] https://youtu.be/FhymQvfjMhY
2. "loop" -> "loop block", non-visual (the loop block is a yellow thing with two teeth and says "while" on it, this is a recall task)
3. Either typing the thing or executing a "find the block and drag it" action. This is the first "visual" task.
Sure, maybe if the kid genuinely can't type but can do gross + fine drag tasks than scratch is a winner, but this is not "visual programming". All the work is still not visual.
The direct text entry programmer has to:
1. Decide what they want to happen next
2. Figure out the syntax to make that happen
3. Write out the syntax
Our visual programmer:
1. Decide what they want to happen next
2. Figure out the syntax (now "big green two pronged if block" instead of "if")
3. Look over the palette and visually identify the block (expensive! non-facial discrimination is tiring)
4. Drag the block from the palette to the code section (weird UI interaction, also requires both fine + gross movement, also expensive)
Notice that our "visual" programmer still has to execute all the same non-visual steps! We haven't made the actual work visual, we just made the UI really annoying and added a discrimination task to it - which is tiring even for our visual learner.
Text _is_ visual, but it's visually expensive to consume. Brightly colored complex little blocks are also.. well basically just as visually expensive.
We didn't make programming visual. We didn't make the skill threshold lower or easier or even _different_. We just added more work.
I know for certain that this is how I see writing programs in pure text, to the point that I stopped programming in traditional languages; my brain is too high-level oriented to remember all the pesky little details that APIs and formal syntax require; give me high-level programming blocks that you just invoke and place with a few gestures any time.
Unfortunately there are very few general-purpose visual languages, so my options at building automated systems are limited; although fortunately this is starting to change, and a new breed of powerful no-code and low-code tools is appearing that shows promise, so I'll be able to build complex systems again by using high-level concepts as building blocks, without being slowed down by bloody trivial syntax errors.
This is not surprising, because "general purpose" tools have general, highly-composable, extensible syntax. Endowing, e.g. condition operators with their own block shape makes sense when all you have is a simple tool like Scratch where they just "snap" inside if-then blocks, but not so much when "boolean" is simply one of many interchangeable types that might, e.g. be assigned to a variable. Then a condition operator is simply some expression-like element that just happens to return a boolean. Similar things happen with other program elements, like text strings, numbers etc. Custom types start to be needed, and then you need to add whatever the equivalent of a DATA DIVISION is in your Scratch-alike.
At the extreme of generalization, you find things like dependently typed languages where even "values" and "types" are no longer separated by rigid syntax, but are the same kind of program element.
And don't tell me that textual programmers don't realize the benefit of secondary notation and visually-conveyed details. We love when our IDEs full with syntax highlighting for different types of operators, global structure mini-maps and intellisense auto-complete tooltips. All these are visual tools that improve the flow of building a text-based program.
Take a moment if you haven't and boot it up. I think there are web versions available now. Give it a go. Build a (simple) program.
There's a reason it keeps not really taking off.
I'm not saying text entry is free. I'm saying that the palette concept is more expensive - even for visual learners. Obviously languages (block based or text) can be easier or harder, eg python is less fussy than assembly.
What visual/block based languages do you use currently?
I've seen scratch used in dozens of coding sessions for kids, and know it used used in hundreds of schools in the UK.
Yes, people only use scratch for a while, almost no-one is writing huge programs in Scratch, but that's not what it is for.
I remember someone building a whole environment for making Slack look professional, by providing a text syntax that could nevertheless be programmed like Slack by adding and connecting typed blocks in the text structure (though I can't recall its name).
I was referring to your defense of textual programming as inherently superior, which I don't see as justified. Classical languages have a refinement over decades that visual languages lack, but I think it is possible, and I think we are getting to a point where building such languages is starting to become viable.
> I'm not saying text entry is free. I'm saying that the palette concept is more expensive - even for visual learners
This is simply not true. Recognition is easier than recall, even for textual learners; so even if toolbars require more steps, those are way easier steps. Even if you're talking about expensive in time and not actual effort, physically entering code is the task that less actual time takes of programming: thinking what code you need to include takes much more time, so anything that reduces that time will accelerate development. Programmers usually are not aware of this fact because they are distracted by all the thinking, but the actual input method is usually not that relevant except for people with disabilities. (Btw visual vs word learners is largely a myth; the best style is usually to the task you're doing, and we are all able to do both styles. When I say I have a preferred style, I do find visual tasks easier than those requiring word recall skills).
Also, nothing prevents visual languages from incorporating fast introduction tools other than palettes, like keyboard accelerators and contextual search - i.e. you type the name of a component and it appears at the cursor point; this would make them work with identical interactions as pure text programs. (BTW, I consider intellisense-autocomplete to be a visual tool; it favors recognition over recall by showing you the list of available options).
What I consider a programming language is somewhat different from what think of as visual languages (which are primarly the flow-based block graphs; they have their place, but are too highly oriented to bulk data processing). For me, the ultimate visual language is the spreadsheet - a functional reactive environment where the user can freely position information and transformations in more than one dimension, and manually decorate them with as many cues, reminder text and color codes as needed.
Some new development environments are growing a modern style, highly evolved with respect to the classic IDE, which is still based on the batch model of the mainframes in the 60s:
* Jupyter-like notebooks bring some of the spreadsheet benefits to classic languages;
* relational models that show data together with structure, like Airtable, is an example of these breed of visual tools for building data-transforming automations;
* wikis work as visual storage that makes it easier to structure and organize hierarchical content;
and so on. Modern development environments will start incorporating all these models, relying less in pure abstraction and running the program in your head as requirements to build programs.
I agree with this point
> was referring to your defense of textual programming as inherently superior,
This is inaccurate of my views. It's not that "visual programming is bad" it's that everything we call visual programming is not actually visual! Scratch is not visual. It's just text programming with more steps.
> For me, the ultimate visual language is the spreadsheet - a functional reactive environment where the user can freely position information and transformations in more than one dimension, and manually decorate
I'm sympathetic to the concerns here, eg users needing to work in multiple dimensions. I still don't think this is a visual language, but it is maybe more visual than traditional visual languages. A spreadsheet is something like a visual layout on top of a program.
> relying less in pure abstraction and running the program in your head as requirements
Even with a true visual language I don't think the need for a mental model can be removed.
Certainly "Visual" is a spectrum, not an on/off switch. Adding syntax coloring to a textual program is a step towards adding visual cues that improve recognition of its parts. Scratch adds over an imperative language a more detailed visual syntax that conveys the types of control structures and the relations between actions and parameters, and allows filling them in by interactive recognition rather than pure recall; so it's a step further in transforming a classic language into a visual one.
Further steps in that direction include changing paradigms to functional or logic programs, that more explicitly represent changes in state through visual cues, relieving you from having to work them out in your short-term memory. Everything about visual languages is built towards adding expressiveness to the actual representation to convey as much information about the running program as possible.
> I still don't think this is a visual language, but it is maybe more visual than traditional visual languages. A spreadsheet is something like a visual layout on top of a program.
Programs are visual entities - they have a very concrete physical structure of a tree. That's why good indentation is essential even when the parser doesn't care about it at all.
A program Abstract Syntax Tree is composed of very, well, abstract components; a program keywords represent objects quite separated of their final form during runtime, i.e. their actual values, but their connections can be often understood in terms of their spatial relations. Our brain is really very good at that, even for textual representations.
> Even with a true visual language I don't think the need for a mental model can be removed.
Completely agree. But building a mental model is way easier when working at several levels of abstraction at the same time, i.e. both concrete values and the abstractions that tie together those values in a concept encompassing them (see the concept of the Ladder of Abstraction).[1] And being able to actually see the values of variables and the connections between processes that change them, instead of having to imagine all those by running the program in your head, is a large advantage. The debugger is the quintessential visual tool, letting you inspect the true relations and processes of a running program through interactive manipulation, even for languages that otherwise lack any visual cues while being built.
It turns out that creating a 1-to-1 mapping between code and diagrams was basically impossible and you ended up with unreadable code and unusable diagrams.
I'd also argue that simple diagram-generating tools are quite viable when used to make sense of a large code base at the highest level, even though I agree that the theorized "edit and generate code" workflows don't work nearly as well in practice.
Strongly (well, moderately) disagree, but not necessarily because I think the Scratch language is well designed.
My nieces both started out in Scratch, and I don't know what they liked about it, but they bounced off everything else I had been trying to show them. It might have been the community aspect (I strongly suspect this had something to do with it), it might have been that Scratch is so limited that it stops being intimidating. I feel like there is a culturally taught fear of text editors among modern kids; my nieces are around really supportive people who think they're smart and encourage them, and I still think they still feel this sense that text editors are not designed for them? Could be my imagination.
I don't know what to think about it because I don't really 100% know why they (or anyone) likes Scratch. I can not stand Scratch, everything is way too hard to do, it lacks so many basic features that you have to approach every problem through the lens of some completely alien architecture where you're doing meta-programming to get basic stuff like dynamically allocated objects. This is a tool that is so limited in so many weird ways that it makes programming way harder than it should be. Everything about it from the UI to how it's structured to the performance: for me, it just makes programming into a chore.
But I can't deny that there's something there that makes it more accessible than other platforms -- and watching my nieces get into it was a big lesson to me in the limitations of saying, "but they're smart and understand the concepts of iteration and variables, why can't they just write Javascript?" They could, they're smart enough to do that, but Scratch resonates with them and Javascript doesn't.
I sympathize with the author's point of view (part of the reason I can't get into programming games is that everything enjoyable from them I can also get... programming). But there is something to these platforms like Scratch, Pico8, etc, that undeniably hits some people in a way that a traditional language doesn't, and whether or not Lisp/JS/C could capture kids the same way, something about them or the ecosystems around them is not measuring up for some kids. Some other kids are the opposite, probably. I got into programming with Flash/TI-83 Basic; I'm not sure where they on that spectrum between toy and tool they fall.
Not for blind kids. Yes, maybe I bring up that kind of accessibility too often, but using the word "accessible" was just asking for it. :) And seriously, that matters in a public school environment.
Fortunately, using a haphazardly designed mainstream language like JavaScript isn't the only alternative. Check out Quorum: https://quorumlanguage.com/
That is a very good point, and yet another reason why it would be good for something else other than Scratch to take off (particularly in schools).
I honestly am not 100% sure what makes Scratch click with people, my best bet is it's the community features, which are one of the few parts of Scratch I think are reasonably good. But it could be other stuff too.
Quorum looks interesting, but I don't know if the problem is that mainstream languages like Lisp/JS/C are too complicated or if it's something else. I feel like both of my nieces would be capable of writing JS without too much trouble if they actually wanted to (but they don't and I'm not going to force them). I also vaguely feel like Scratch is straight-up harder to work with than JS for some problems. So I'm torn with whether the compromises it makes are helping it be popular, or if it's popular in spite of them.
Scratch (on top of being a drag-and-drop block language) is also very visually oriented in the types of programs it encourages people to write. And that might be a contributing factor for its popularity with sighted kids, but obviously is not going to translate very well for blind/vision-impaired kids even if the interface itself was made more accessible. I strongly suspect Flash would have had the same problem back in the day (assuming that was accessible, which... I haven't checked but I also suspect it probably wasn't).
I wonder if there could be some cool things that would be possible to do nowadays with pre-packaging a bunch of decent-quality sound effects in an engine or setting up some of the AI-driven voice tools that have been popping up online and letting kids start programming with them.
This is a weird criticism, learning type declarations will not make someone worse at programming or rot their brain. It's mostly just syntax.
As a point of comparison, Scratch doesn't let you assign object instances to variables. I just can't imagine getting worked up about type declarations in comparison to that.
> for a world that mostly no longer exists.
Also... casting no longer exists? I still do explicit casting in JS on occasion, and it certainly comes up in C-like languages. Correct me if I'm wrong, but I don't think Rust even has implicit type coercion at all.
Scratch is a great "first step" for getting your feet wet and playing in the shallow end of the pool, as one is learning to swim. Not everybody learned or were even taught to swim their first day at the pool, and everybody has a different schedule on when (or if ever) they will get good at it.
I don't know if that's good or bad--maybe a little of both. It seems like overcoming syntax errors is a pretty good first-pass filter for determining if one has the mettle for coding. On the hand, not everyone is a professional builder, but it doesn't hurt to know how to tighten a screw or swing a hammer.
The advantage to syntax though is that it's all verbal which makes it far easier to communicate. Visual stuff needs multiple images and often video to fully communicate which is slow and more constraining.
>Learning syntax as a filter
Syntax is one of the most universal things about our psychology. The idea that some people have it and others don't seems a little absurd to me.
>Syntax is one of the most universal things about our psychology. The idea that some people have it and others don't seems a little absurd to me.
Sheesh. Care to put any more words in my mouth?
I said nothing about whether or not someone _could_ learn the syntax of a programming language. My comment was specifically about the difficulty of learning to program while also navigating arcane syntax rules (in the sense they're unfamiliar and rigid) that come with most programming languages.
If you want to write code you'll probably power through it. If you don't, you might decide it's just not worth the trouble.
This isn't a value judgement on the individual. I'm saying it's a pretty good indication if someone has the temperament for coding. If you're unwilling to understand syntax errors, how likely are you to debug your program?
Kids are into what kids are into. I have introduced every 'STEM' toy on the market for my kid, plus played with Scratch, Arduino, Python etc with them. Gave them a laptop running Linux when they where 8. They don't care and are completely uninterested in any of it.
The goal is to give them enough base that they will be able to catch up whenever they decide or whenever they need. And so they dont end up clueless or scared of technology. I think that scratch does that job to large extend - they learn a bit of thinking procedurally, have some fun with moving pictures and them move onto something else.
Also, most programmers were not obsessed by the age they were 8. A lot of good programmers started to seriously approach it only later or after then encountered something that clicked. Or had this as one of many interests. All of that is fine.
Unfortunately such tools don't really exist nowadays, maybe Roblox, but nothing outside of that.
Check out Godot, which has tutorials for creating a game: https://docs.godotengine.org/en/stable/getting_started/first...
There is also the Blender Game Engine, which got split from Blender, but has a visual logic editor: https://upbge.org/#/documentation/docs/latest/manual/manual/...
Kids tools should be far more limited, it's useful both for creativity and to stop most crazy ideas, since they would be impossible.
Finally, it's a giant pain to get anyone to actually play what you make. How is a kid going to handle compilation, executable distribution, and much more. If you send an exe via email, the spam filters will catch it, if you find another way, the operating system will yell at you for starting an unsigned executable. If you want to make a web game, you'll have to figure out hosting, design, JavaScript, and all the rest. Sure, you could teach a kid this, but it would take months and any one impediment can stop the whole process cold.
The fact that I was able to figure out most of this stuff on my own, much of it without internet, goes to show that the tools I used had the perfect balance of complexity and limitations for my age. Of course nowadays I've moved way past them, but I can clearly see there's a gap in the mid-level tools that sit somewhere between a full programming language and Scratch which is too simplistic.
Interestingly enough, Arduino fills a bit of this niche. It's relatively easy but quite deep, perfect for a gifted child. The limitations of the electronic components also force you to push the limits of your capabilities in a way that a blank canvas just overwhelms you with possibilities.
- Scratch has an integrated 2d game engine, sprite editor, and asset library. This makes it easy for kids to make something of interest to them right away, including those who don't pick up coding right away. I've had kids who struggled with complex coding but were still able to enjoy Scratch by making lightly-interactive stories / art.
- Most children can drag blocks faster than they can type.
- Most kids these days aren't familiar with a lot of desktop computing concepts we take for granted. For instance, they mostly don't know what files are, or how to copy and paste text. It would be nice if I could teach them all of that before any coding -- but that's generally not what they feel they're there for.
- Scratch shows the current value of variables by default. This helps kids to grasp the concept of a variable and to understand why their program is behaving the way it is.
- Scratch is a website, which makes it easy for kids to show others what they did. This makes it more gratifying for kids and parents. IIRC, the Scratch team also found that this aspect is especially appealing to girls.
Maybe, these were some things I lacked the most in my early training:
- Documentation: in the second half of the '90s the Web was too young to provide docs or even answers to my doubts. The open source community was confined to universities and there was little chance for my parents to know how to access a BBS.
- Tools that give a child agency without the need to read documentation: most things I could do as a child were because I either had clear examples of how to do them, or because the tools themselves used visual UX paradigms that any curious human could grow their skills by experimenting. Kids can devour technical manuals, but keep in mind that not all kids (nor their parents) speak English, and this can seriously limit their agency.
- Free (or even just accessible) professional tools to move on once I had mastered their watered-down for-kids cousins. Dad knew about interpreted programming languages, but had he known the word "compiler" (or "synthesizer" for that matter), I could have mastered them much earlier.
- More guidance. Curious kids can do anything, but if there's someone leading the way or offering a benchmark, they can really bloom early. A young cousin of mine, displaying surprising sauvant traits, is lucky enough to have artsy and technical parents, and I can see how far he's going!!
Speaking of the proposed language, I'm not sure kids would particularly like LISP like languages. But when I was a kid I wouldn't have cared, had I known someone knowledgeable.
Thinking back to my own early programming on the Commodore 64, the ability to make something flash or move or otherwise resemble a video game was very important to me as well. Some kids are interested in and motivated by math, but that hasn't been my lived experience.
Scratch looks close enough to Python and JS but made visual that I'm not sure I see the issue. Is there not already a math class in school where people go to learn the low level information?
CS and programming are separate. If we don't work in simple languages with clear axioms, then why not teach what people actually use?
Lambda calculus is probably a fantastic tool to really understand the deep fundamentals and theory though. But I'm not sure starting at a low level like that is the best.
Our family avoided Scratch for many of the same reasons the author gave. Instead we focused on typing and math and introduced programming when typing out all of your code wasn't going to be frustrated by their typing speed.
How to Code: Simple Data with EdX is a very nice introduction to that approach of teaching programming.
It's the tool that I use whenever I try teaching kids to program.
I want to evaluate lamdatalk against scratch on the principals on which scratch was built, low floor, high ceiling, wide walls:
Low Floor: I can show a child the program "when space key pressed, Move 10 steps" they'll need to be able to read, and they'll need to know what the "space key" is (they've been weaned on touch screens remember), and then they'll understand it. further, they can then hit the space key and immediately see state change. They can use scratch on any computer they have access to at home from a browser.
Lambdatalk will also require them to know how to read, and I'll need to explain what "lambda" means to a young child, and probably how to pronounce it. I'll need to say what the arguments to a function are, and what "argument" means, and what way round they should go. I'll need to explain to them why they should care, a moving character is immediately interesting to a child, this lambda has limited use to them. if they want to type it out I'll need to show them how to type a curly bracket. They'll need to download and run a program to use lambdatalk, on a PC they probably don't own. (or use this inscrutable sandbox I guess? http://lambdaway.free.fr/lambdaspeech/?view=sandbox)
High ceiling: There's a lot you can do in scratch, people regularly post rudimentary raytracers or highly polished games on the scratch website. That said it has some limitations. It doesn't interact with the web at large, it's slow & hard to do work in 3d, and impossible to match the likes of a real game engine, kids tend to want to graduate upwards after a while.
I was expecting to find http libraries or some impressive demos for high end lambdatalk, but I can't see them, it may be more performant, but I can't actually see the same level of demoscene work as exists in scratch. I wasn't expecting to but I've got to give this one too, to scratch
Wide walls: Kids make games, animations, toys, mocked-up os'es, sounds, and conversation bots in scratch, there's a lot to do with it
Lambdatalk just, doesn't have so much? if a kid says they want to make something in scratch they often can, unless it's 3d or requires wider internet access, lamdbatalk doesn't seem to provide so much.
In conclusion, don't rag on scratch for clicks, it's an educators miracle, and when kids want to "graduate" up to more, they're looking for more possibilities, not harder challenges, like html, or python libraries that let them interact with the web, or 3d engines that let them make the kinds of games they like to play. As an adult I think lambdatalk seems like a cool toy, and I'll put some time into playing with it.
kids want to make the kinds of things they like to use.