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.