One of my earliest memories of writing code was playing Gorillas, a QBASIC game, on my school's PC in the early 90s. My friends and I would tweak the source code to make the gravity stronger or weaker, or make other interesting mods to the projectiles.
For me, it was a perfect introduction, because there was an already written, already playable program, and I could dive into the code little by little and explore.
Scratch is very similar. My kids love to play games on Scratch, but they also enjoy taking a look under the hood to see if there's something simple they can modify.
This is something that I think is extremely under-appreciated: the ability of a user to dive into the code of what they’re using and try things out. Like the type-in games of the 8-bit micro era, or like Scratch, or like Emacs; each of these allows the user to tinker with little overhead.
Modern software, by contrast, is usually too opaque - even free software! The barrier to entry is way too high.
Minecraft is also slightly an outlier, I would say; its modding community has put a lot of work into making it easier for people to get started. It’s still a far cry from having a “view/edit source” button, though.
If I remember correctly the early days were painful as well, with it being necessary to manually unpack the jar file, and work with deobfuscated decompiled code. I'm not sure what the state of it is nowadays, but I hope its more pleasant.
My favourite game from a modding perspective is Kerbal Space Program. Just drop a Mono/.NET DLL into its GameData folder and you're good to go, and code completion works automatically during development as long as you have Squad's own DLLs in the right paths.
If you used the Forge development environment, then it did the deobfuscation for you. They have it set up so well you basically don't even realize it happened.
These days Mojang provides obfuscation maps, so you can work with proper class and method names (though no parameter or local variable names). There's also been a lot of effort been put into the tooling. Nowadays there exists Gradle plugins that will download the game jar, decompile it and deobfuscate it using the official mappings. You develop against the deobfuscated code, then the plugin will turn the unobfuscated names back into their obfuscated versions when you compile.
There's also been technology developed that lets you easily modify specific parts of a method in the game, so you can e.g. insert calls to your own functions at runtime.[1] This saves from you having to modify the game jar itself.
Yeah. I have a lot of respect for all the Nintendo emulator makers and homebrew hackers, but for the platforms themselves, I can't help thinking the world would have been better if something else won out.
Wii actually had a web browser and JavaScript API for the Wiimote controller. This comment made me remember a basic website I made for it back in the day. It was cool to use the Wiimote to interact with the page! The web games didn’t really take off though. I wonder if Wii emulators have the browser app? Video out broke on the Wii consoles in my family…
I have a 4 year old and I find that he’s not ready to be exposed to computers let alone programming languages yet. There are so many things to learn at that age that sitting in front of a screen for too long may be a disadvantage. Im thinking a starting age is more like 6-8, of course depending on other factors as well. I find that 3-4 may be a good time to start reading though
Our (then) 4 year old got the hang of Scratch Jr on the iPad really quickly. It’s great and gets kids used to sequencing, basic logic, loops, control flow and more without needing to be a confident reader.
She loved, and still does love, drawing her own sprites and recording sound effects to create interactive stories.
That brings back some very fond memories. Another game included in MS-DOS was Nibbles. I still remember wrapping my head around how Nibbles worked, as the source code didn't seem to fit the actual logic being run. It just looked way too short and simple. That's before I discovered how to view the source code of functions in QBasic. Then it clicked.
The Internet Archive has these games available to play by the way:
That is brilliant, thanks. Takes me back. I didn't do much programming in QBasic, but I do remember that interface. I just now debugged Gorillas with a breakpoint and checked one of the values in the immediate window. It is quite a nice debugging interface, considering the constraints! (Actually it has a nice "just works" quality about it of something where the same people came up with the language and the ide and it is all designed together. Classic VS has this feeling too).
I think in a way it’s a shame that kids now first see visuals rather than code.
There’s something much more thrilling about seeing a bunch of written instructions become a game, than some sprites that already look a lot like the game start moving about.
Another awesome QBASIC feature - the help section taught you everything you ever needed to know to learn every feature.
I assume that Scratch is more accessible to very young kids, who may have trouble with the ergonomics of correctly inputing text. Also, the whole "drag and drop" workflow can potentially be better suited to modern touch-based devices.
There's also the fact that –let's face it– code is intimidating. Having a ui
- that looks more like what children are used to in everyday UI
- that is *localized*: in general programming languages are centered on English. Most young children in the world don't speak a word of English (beside "hello, what's your name?" If they had the luck to get English classes in grade school)
Have you tried scratch? The blocks are written programming instructions, with some puzzle piece connectors which help avoid basic syntax errors. These instructions drive the sprites.
I’ve tried it on the iPad. Does it work the same there?
I still think it’s more awesome to see just a written sentence that I typed out become something. Once you introduce any form of barrier between that and output, it’s hard for anyone to know what’s really happening behind the scenes to help you.
There’s a beautiful purity to just simple text becoming something awesome.
Typing can certainly be more productive. However, it can also be error prone. You might checkout Blockly (the lower level language used to implement the current version of Scratch).
A lot of the stuff we type out in code is syntax and templates. Like this loop:
for (let i = 0;
i < cars.length;
i++) {
text += cars[i] + "<br>";
}
Starting out, it’s hard to tell if the program syntax is wrong or if the program logic is wrong (just getting the snippet above to look close to right on HN is a pain :-)). Blockly makes that easier by mistake proofing the syntax so the programmer can focus on the logic, variable names, etc.
I was randomly messing around with a Chez Scheme REPL of all things recently. My 7 year old wanted to have a go. So I got here to do basic (+ 1 3) type stuff to add numbers. I think what made this work is I didn't explain anything, she did it, and if there was an error I would say why. She didn't question why the plus was at the beginning not in the middle like at school. I guess what I am getting the feeling of is "monkey see monkey do" might work better than "big tutorial-type explaination". Kids will understand - they have the intellegence to understand "the thing", but not necessarily will they understand the abstract dry way adults describe "the thing".
Also applies to adults somewhat - Monad tutorial vs. just use a few monads and see what they do.
One-on-One learning like what you're describing is kind of the holy grail of all education, or the second-holy grail after finding ways of making students interested in things they don't yet know/understand (which is also the case most of the time in the parent-child bond, because kids are interested in whatever daddy and mommy do). This kind of enviroment takes the child from being a helpless ape to a functional human with intricate understanding of very complex rule sets (language, society, technology,...) in about 15 years.
But learning enviroments are typically the more inferior Many-To-One variant, so even if your child isn't confused by RPN, and even if (n-1)/n children aren't confused by RPN, the teacher must clarify it nonetheless for the 1/n student who is (or appears to be) confused, a book writer might have even less options and more constraints.
Basically, education is a very complex human-to-human Serialization-Deserialization problem. Knowledge isn't what's in the books, or the video lectures, or on github, all of those are just on-disk "dead" representations, the result of calling toString() on actual knowledge. Knowledge is all the intricate in-memory data structures built up in all the human brains that are currently living. The problem of teaching is : given a brain, reconstruct some of its internal data structures in another brain with an error not exceeding some threshold.
It's bad enough that you have to serialize the very rich and graph-like patterns in your brain into flat streams (words, pictures,sounds) to transmit it, it gets much worse when you have to do it for multiple brains simultaneously, because each brain parses streams differently. The more brains and\or the less you know about each brain, the worse your teaching performance and the uglier the representations you come up with to transmit your knowledge.
This isn't to say that teaching is easy when it's parent->child, just that (assuming reasonably healthy bond) it's as good as it ever gets. A single receiver who is extremely interested in whatever you have to say and will re-try on error a lot of times to understand it, that's the teaching problem on easy mode.
That's what I did also. I made explosions in Gorillas as I wanted them . I didn't know coding or language but somehow figured out if I change values here and there the explosion would be bigger.
Soon after that wrote program for deleting other programs. actually useful because we didn't know yet how to delete from DOS.
we were kids left with PC with no instructions at all. Parents were busy.
Now in hindsight I see my first steps were somewhat destructive.
I too edited gorillas as one of my first programming endeavors.
As for the other thing, there was some DOS command I learned that forced an immediate reboot. I realized this could be added to the end of an autoexec.bat and create an endless reboot loop.
Well, I thought this was a funny prank so I edited the file on a display PC at Costco. Came back by it later in the trip and it’s still booting and rebooting.
I look back on that and realize it probably had to be replaced and sent to some other state where some tech either had to troubleshoot it or create a new image all together.
Not the best use of value but it was amusing to exert power over computers at such an early age.
This path of playing a game, wanting to learn more, then getting into computers and coding is actually really common in parts of the world where computers and computer-based educations aren't as wide spread.
I hire a bunch in Latin America, Middle East, etc, and every interview my first question is always "why did you get into software?" and I'd say more than half of people I interview got into coding in one of two ways, either gaming, or building websites. I'm interviewing people who learned to code more than ten years ago, when websites were HTML with some PHP and gamed were much more accessible. I'm not sure what the corresponding path would be these days.
Modifying gorillas? You and your and friends were rockstar programmers already. I remember looking at the source code and thinking "this must be black magic".
Thanks for bringing back the memories though. I looooved playing gorillas!
I remember actually crying from frustration because I couldn't figure out where the bananas were drawn. I desperately wanted to change it into something else.
From a quick look it doesn't seem that the graphical elements are inherent to the language. It could be expressed in a text syntax, and with more or less difficultly other languages could get a similar graphical overlay.
If the graphics are useful training wheels to new programmers of scratch, the same is probably true for the text languages. And from time to time even a super cyclist can find a use for training wheels.
For one thing, a language expressed in a common graphical form could help communicate with non-coder domain experts, quality assurance teams, customers, etc. This is kind of an argument to publish the latin bible in the vulgar argot, less exclusive to the priesthood.
They took the basic idea of Scratch, then made it into more of a game with levels, each level being a puzzle to (implicitly) teach or test programming concepts. As you progressed it'd introduce new syntax, while slowly "fading" more familiar syntax towards actual JavaScript code (though retaining the block/GUI-based interface).
We did some more work on further iterations but I'm not sure what became of it all.
Resnick and co were very structured and evidence lead with the graphical design; nothing in the visual language is accidental. The structure of the language is also very carefully designed in conjunction with the graphical mechanisms.
There's a common fallacy that the technically minded are prone to, of assuming that since two different things are 'essentially' the same, the differences between them are superficial and unimportant.
So, for. example, since Scratch. and a text-based language with similar structures (Python, say), are 'essentially' the same, the graphical elements. of Scratch are just sugar, or fluff, and should be ignored.
It's the same mindset that says since anybody can get an FTP account, mount it locally with curlftpfs, and then use SVN or CVS on the mounted filesystem to version control it, there's no need for such a thing as DropBox.
Advice for the terminally reductionist-minded: Maybe the things that make Scratch different from Python are actually the most interesting thing about Scratch.
Totally agree - the details are critical. There are a thousand details that can derail a child from understanding programming, if you deal with 999 there's still one that will get them.
The same mixed media programming existing in the Lego Mindstorms platform when I was a kid.
A bunch of my peers where using the visual editor, but I took the plunge and learned NQC to do my programming. Having multiple paths available to users helped the platform and broadened its accessibility.
I'll never forget the instructor teaching me to always make sure my curly-braces matched up. :)
This is extremely heartening. I can’t wait for the day we get popular Smalltalk apps that users can easily inspect and modify! Seems like it’s actually a great platform on which to bootstrap a free software ecosystem more effective (for remixing) than GitHub.
College student here. Scratch was my first real introduction to programming. It's an amazing tool, and a great way to get anybody started with programming
For beginners up to about 12 years old, Scratch is optimal. For older ones I think a text-based language is better. In the past, that was BASIC. Today it can be Python, with which beginners have some problems in my experience. And now comes the shameless self-promotion: I have developed something that can fill this gap. By the way, it is open source.
I like how under the (more) menu, you can step through the code. It not only teaches kids how their code works, it also indirectly teaches them how a debugger works.
Where the trace shows, it would be even better if the variables could be edited, which brings it even closer to debugging, and also expands on how the program logic works.
I've seen Scratch described as "learning how to talk before learning how to spell".
For beginning programmers, memorizing syntax is a major source of cognitive load. As a result, it's harder for them to practice the computational thinking skills that coding is really about. Scratch removes this barrier.
I actually think Scratch is a good tool for beginners of any age, including adults.
I like Scratch - my kid uses it and I worked briefly with the guy who made Blockly, the underlying visual programming toolkit - but the programming environment makes many things far too complicated with its singular focus on sprites.
It's very, very difficult to do things as simple as display a number on screen. My 7yo was making a number guessing game, and to display a two-digit number we had to make two sprites that had 10 "costumes" (0-9) then do modular math to select the costume for each digit. Sprites also have their own code, and if you duplicate one and edit the code the edits don't apply to the duplicate - so there's no user library or abstraction power at all.
This made dealing with Scratch far more complex and time-consuming than the logic of the game my kid was making, which is the exact opposite of what you want in a learning environment. I don't really want to focus on the idiosyncrasies of Scratch when teaching programming.
Some simple text and drawing commands, user-defined functions, and a library would go a huge way towards making Scratch simpler. There are some other Blockly-based environments that may have this... but they're not as popular.
> It's very, very difficult to do things as simple as display a number on screen.
I suppose I might be missing something, but if you just care about displaying the number, rather than any particular styling, you can just show the variable, right?
Show the variable how? There's not a console, there's not a way to simply display a string or character. Scratch revolves around programming sprites to do things
Tick the checkbox next to the variable in the block palette. That creates a variable watcher on the stage. You can also right-click the watcher to change it to a large readout, displaying the variable contents within a minimal frame.
We ended up redesigning the app to be better for "say" and "prompts", but our original design just had a couple of big number displays on the screen and a button - something he literally drew out first on paper. We had to basically fail at that before making it more text based.
> My 7yo was making a number guessing game, and to display a two-digit number we had to make two sprites that had 10 "costumes" (0-9) then do modular math to select the costume for each digit
So if your kid is cool with this kind of clever workaround for the limitations of some piece of crap, you have a future software engineer.
Exactly! I think the value of these programming environments is in helping you find new ways to think about problems. Having constraints/limitations can be one way to force that creative rethinking to happen sooner rather than later. Obviously you need to find a good balance though as causing frustration and helplessness would have the opposite effect.
I’ve an anecdote of my own that I still think about semi-regularly:
I was volunteering at a school for a year or so helping them teach 9-11 year olds Scratch. Most of the kids spent the term trying to move sprites across a canvas and making basic platformer style games. It was a heap of fun while also challenging at times.
One day one of the students grabbed my attention and asked for some help making something work. She’d decided to build a trivia game, and was having an issue working out how to make the text for the previous question disappear. When I looked at what she’d built I was blown away. She’d basically built a fully recursive function in Scratch that would iterate through a collection of questions & answers. It was built almost exactly like I’d expect a professional developer to build something. A simple reusable function. I didn’t teach that. She’d never used Scratch before. She’d not done any programming before. It was just the most intuitive way for her to do it.
Seriously, I remember programming in constrained environments, for example in a calculator, and how that seemed to boost my creativity. I wonder if something is not lost (in terms of learning) by having such hugely powerful systems with any non-trivial functionality a simple library download away.
Or, as another example, try processing a file of hexadecimal numbers in POSIX standard Awk.
Another one: a few months ago I wrote an Awk function which can increment an alphanumeric string, like "A0Z" -> "A1A" -> "A1B" ...
I had to write a BEGIN block which populates global hashes for looking up the successor of a character, and whether it wraps around in its class. By character, I mean string of length 1, of course; there are no characters in Awk.
This is why professors try to limit what students can use in their assignments. And then students (and the internet) turns around and chastises the professors for putting restrictions which the students will never encounter in real life.
I agree. My best memory during my school days is still the supreme satisfaction I had of implementing a complete gaussian elimination algorithm in assembly using only the puny number of registers in an 8051.
If you’re willing to pay then give gamemaker studio a go. It has a similar logic block based model (you can also progress into a full ECMAscript based language once you get more advanced), but is a lot more flexible about what you can display.
Not 100% sure it’s still beginner friendly as I used it over a decade ago, but I’m pretty sure there’s a free trial, so you could find out.
Wat? Really. I thought it just has GML which is one of the shittiest languages I've ever used. It's really and seriously crap. On par with trying to write real programs in sh.
>7yo was making a number guessing game, and to display a two-digit number we had to make two sprites that had 10 "costumes" (0-9) then do modular math to select the costume for each digit
This, imo, is what makes Scratch a great education platform. It has a couple of very easy to use primitives (such as displaying and moving sprites) and leaves you to build whatever else you need by abstracting things on top of it. This teaches you one of the most foundational programming skills: how to do something complicated with only weird, rudimentary tools.
I just think there are so many other forms of distraction today. Young kids are carrying around cell phones, texting their friends. It’s that or they are doing something on Tiktok.
Yes true for most people ( I am 13, Started programming in Java with 10 ) but some also do this other stuff. Like I installed ubports on my second phone today ( Writing this on it )
Never heard of ubports. Looks interesting. A 40 year old just learned something from a 13 year old. If this is how you're spending your free time, then you have a bright future ahead of you. Keep it up!
You should consider this interaction as an opportunity to also revisit your ageism. I'm all for encouraging young people, and OP seems a really bright 13 years old person, for sure. But try to keep condescension out of the way. As anybody with children can tell you, we all learn from them all the time. It's not something surprising.
I find hard to interpret "A 40 yo learned something from a 13 yo" in a non ageist way. Seems that people disagree, but nobody has provided a counterpoint.
Actually, the comment in question would have been perfect encouragement in my view just by removing that phrase.
I think you are the exception, not the rule. I teach Scratch, MakeCode, and Microbit to kids at my daughters school. Only a small fraction take it serious and get into tinkering and making stuff.
Displaying a number sounds like some hello world popup exercise that you would do in Rust or Go. I don’t see why one not just jump right to the game-making, which Scratch is good at.
> This made dealing with Scratch far more complex and time-consuming than the logic of the game my kid was making, which is the exact opposite of what you want in a learning environment. I don't really want to focus on the idiosyncrasies of Scratch when teaching programming.
Printing “Hello World” and displaying a number is easy in languages like Java. Making a top-down shooter is not. So why does one usually do the print stuff rather than the top-down shooter stuff? Ain’t that also because of the idiosyncracies of your run of the mill general purpose programming languages?
Probably because his kid wanted to make a number guessing game? I feel like the last thing you would want from a children's programming language is "why would you want to do that? Go learn Java if that's the type of thing you want to make"
It seems like Scratch is made specifically for game development, since everything revolves around the concept of manipulating sprites. "Guess the number" is a game, but not the kind of game that this tool was made to create.
Shameless plug: we're running a Scratch-like site, but for terminal programs (among other runtimes). A number guessing game is one of our example programs. It's about 20 statement blocks: https://app.code-it-studio.de/project/303
There were a couple ways you could have made it easier, but Scratch's constraints and abilities can be hard to navigate or understand. Like you can use Say, or a visible variable, and I think the drawing extension would work too.
It's good that Scratch doesn't change that much, there's lots of books and traded wisdom that retains its value as a result, but there's also some big missing pieces that make some things very hard to write in Scratch, and they could be improved upon but they aren't
If I recall correctly, Scratch existed before Blockly, which was developed by Google. The excellent Microsoft MakeCode environment also uses Blockly and looks like Scratch with the important distinction that you can switch back and forth between blocks and Typescript anytime.
Even with that feature, there is no "UI" capability. Getting stuff on the screen still consists of putting up sprites with words over their heads! I ran into this while developing two games on the platform, like this one: Mathtown Alley[0]. It's a crippling limitation even for me, and I write TS professionally.
Look I was teaching myself Z80 machine code on a ZX-Spectrum when I was 11. No internet to help me out and nobody I knew could help me. Just one book. And yet I learned how to hand compile Z80 assembler to machine code and make fun little games. So don’t underestimate the capabilities of kids to solve hard problems :)
That's different. You were learning from first principles, using the lowest level primitives, and how putting them together made it possible to do an almost infinite number of things. That is powerful and intoxicating.
With Scratch you are given a limited set of blocks that are designed for a limited set of solutions. It is at the same time not particularly powerful nor does it feel like you can grow your solutions to anything you have in mind.
I have three kids and have taught (or attempted to teach) each of them programming. I started with Scratch every time, but it never piqued their interest, although they understood it. I have since started them on Javascript from the very basics (Khan academy) and they are very curious about each new lesson and the weird powers it brings. YMMV but people should not assume Scratch or Mindstorms and so on are necessarily better learning environments, just because they are 'friendly' - it can be quite the contrary.
Yep I agree. I don’t think learning Scratch is a good way to learn programming. The intentions are good but IMHO misguided. Scratch is too “abstracted away” from what is really going on. Learning about the lowest possible abstraction (machine code) made it easy for me to understand everything else in programming. And the humble BASIC programming language taught a whole generation of kids how to program. So I think it is fair to state that BASIC is a proven way to teach kids the “real” stuff. Perhaps Python might be a better choice today?
One of the game changers from back in the day, which makes teaching 'real' programming much easier, is the proliferation of very good interactive online learning environments, like Khan, Udemy, etc.
Scratch is great for learning programming for kids/people who it doesn't come naturally to.
Natural developers like myself and plenty of others spent our childhoods hunched over a zx81/spectrum/commodore/whatever because we thought it was _cool_.
I've always thought that number-guessing games were a first choice for introductory coding primarily because they're well suited to the standard library of most programming languages. Once you have standard I/O, you can write a number-guessing game.
Scratch has different constraints than most languages, but I don't view that as a bad thing. Scratch takes what is normally a huge undertaking--sprites--and makes them as much a first-class primitive as stdin/stdout are in most languages. Yeah, this makes the number-guessing and text-adventure games we usually use as teaching projects harder, but it makes it a lot quicker to build visual games. I don't think Scratch needs to change, I think we need to recognize that kids in this generation won't be building the same starter projects that we did growing up.
Back on my good ol C64 Basic I started with art. With the poke function you could put characters on the screen, change colors, etc. Put that in a goto loop and you've got a cool modern art machine.
The sound generator was quite rad too. 3-voice chords. Sines, triangle, etc waveforms.
I agree, my 7 year old is into maths at the moment and he found it easier to just use PHP to do basic maths.
I sat down with him for about an hour and I printed a "cheat sheet" for the various arithmetic operators (just the basic ones) and he's now quite able to just whack a simple script together and execute it on the command line.
Having said that, he wasn't entering the situation completely blind. He's been using a PC with Linux (Ubuntu) since he was 3 years old. He's been playing Minecraft for 4 years (which is excellent for younger kids to learn mouse skills).
I also started him out on GCompris on a laptop. Then we both built a PC for him when he was 5. I got a load of cheap second parts during the early part of the pandemic and I let him do it himself (while observing and guiding).
I started him early because I started early too and I started him off on PHP because I remember it being relatively easy to learn when I was a kid because it isn't a particularly strict language which means a young mind doesn't have to perform a huge amount of translation in their own head, they can almost type exactly what they're thinking and run it.
The command line I introduced almost immediately. It was a way easier method of teaching him to launch apps without my help...I just set the terminal to load on startup and printed him another "cheatsheet" of basic stuff that he needed (no rm -rf * just yet).
If he's in an exploratory mood he will use the menus and UI but if he just wants to get straight into Minecraft or write a script he can just get stuck in!
I can see scratch becoming more interesting to him further down the line but for now, certain things are easy enough.
Typing is an interesting one though...I spent a fair bit of time working on his typing because his handwriting at school wasn't up to par (he's fine now, but his crap handwriting was holding his spelling back a bit). As soon as he became somewhat proficient at typing his spelling improved no end. Unfortunately though, his teacher won't let him do spelling tests on a laptop. Which I think in 2022 is the dumbest thing ever. They've only just started teaching typing and basic computer skills in his class (as of about 6 mo this ago). I had his teacher take me aside and ask me exactly what the hell I did to get him so far ahead. They measured his typing speed at 60wpm!
This all said though, I am an IT guy...so parents with little to no tech skills might not have the smooth ride I had, which is probably where tools like scratch come in...I think it's a tool for non-technical parents as well as kids.
Before scratch though, I'd highly recommend GCompris...but be warned, you need to do it short sessions (20 minutes or so) because kids get bored of it fast.
My youngest is 3 and he's getting second knowledge from my oldest right now as well as the same stuff I did with my oldest...so maybe he'll learn even quicker?? We'll have to wait and see.
I think there is great value in being able to write symbols with your own hand. It’s more powerful to us subconsciously to use extra muscles and see something which is distinctly recognisable as our own making. We are losing a lot of enactive cognition by being on screens in chairs; to societal detriment I would wager.
Since it is from the constructionist tradition, I believe it is intended as a "microworld" [1] so being powerful and general purpose is an anti-goal. It is optimized for trial-and-error exploration, which works best when the functionality is reduced and there are not too many tools in the shed.
Producing text and formatting strings is likely deemed out of scope for that reason. People figuring out clever workarounds is a bonus!
One thing I really appreciate about visual programming languages, especially as I watch the sorts of challenges students encounters wrapping their heads around the concepts in programming, is that the development environment and the nature of the visual language make it very hard to build syntactically incorrect programs. In contrast, text-based languages sample from the sea of all possible strings of characters, and except a vastly tiny subset of that sea as valid input; the rest are just rejected programs.
I think there's a lot of meat on the bones of creating tools that make it structurally impossible to write statically invalid programs. Consider how much time the average developer consumes in a simple iterative process of writing a program, discovering they have made a simple syntax error, and correcting it. IDEs have come a long way in shortening that loop by providing interactive feedback that the current program is invalid, but if the static analysis rules of the language move all the way into the development tooling, you're compiler doesn't even need a static analysis step!
Scratch is great, but the problem is: where do kids go after scratch? Often they are transitioned directly to professional-grade languages and developer tools, which has the effect of turning what was once fun to something scary and frustrating. Many kids stop their PL development right then and there, writing it off as something “not for me”.
I find this sad, as it means a lot of people who might otherwise benefit from programming in their daily lives never pick it up again. Just as not everyone who can cook needs to be a chef with professional grade equipment to benefit from the activity, not everyone who programs needs to be a software developer with all the incidental complexity that entails.
We start teaching Java to kids as early as 8th/9th grade when the vast majority aren’t ready for it. Even my sophomore students in college regularly struggle with the language.
There’s a huge gap between scratch and Java that is begging to be filled by innovative language design. Or better yet, a language that can a student can stick with from early age all the way through adulthood. Imagine if students who started at 11 actually stuck with it through 18 and beyond, instead of giving up at 13/14. Scratch has a perception problem as being something exclusively for kids; I don’t know how it can shed that reputation.
We need to stop treating early childhood programming education as the first stage of the funnel into corporate tech jobs. Not everyone wants to end up there, and we shouldn’t design their education with that goal in mind. Programming literacy is too important in the 21st century to reserve the skill for would-be devs.
PICO-8 could be a next step. https://en.wikipedia.org/wiki/PICO-8
A "real" programming language, but still focused on game making, all wrapped into a neat package.
> Scratch is great, but the problem is: where do kids go after scratch?
Good question, I personally think p5.js is a great option. JS is very flexible, and the live environment (at editor.p5js.org) is I suppose very similar to scratch. Drawing elements like squares and circles is as simple as square(), circle(), etc. (with parameters). It's very easy to share an publish (could be on github[1], or just link directly from the editor!). Highly recommended for beginners and any quick interactive work really.
It would be great to have a community page like Scratch though.
I was planning on providing a pointer to Snap!, so I'm glad timbit did it. Snap! behaves similarly to Scratch, but its underlying language is more powerful (it's essentially a visual Scheme). Were I still teaching university CS, I would be advocating for the use of Snap! in the introductory course.
In the past, Flash filled this niche, I think (although I never programmed in it). Looking at my own list above, and others' responses, I don't think this niche has truly been filled, alas.
> Scratch is great, but the problem is: where do kids go after scratch? Often they are transitioned directly to professional-grade languages and developer tools, which has the effect of turning what was once fun to something scary and frustrating. Many kids stop their PL development right then and there, writing it off as something “not for me”.
I work at a company that runs coding classes for children.
We created https://woofjs.com/ explicitly for the purpose of transitioning students from Scratch to a text based language. It's not perfect, but worth a look!
I wonder if there's a way to smooth out the transition into modding "real" games that teenagers are already playing with their friends. I'll bet it would be pretty motivating to have that kind of power in these online spaces where a bunch of your friends hang out.
Minecraft and Roblox support mods written in Java and Lua respectively but it's a pretty big leap from Scratch to Minecraft mods.
I was recently discovered a dedicated editor for Minecraft modding (https://bridge-core.app) and that seems pretty cool. A lot more could be done in this space though.
I've been asking myself the same thing recently, and recently ran across LeopardJS -- it's meant to bridge the gap between Scratch and JavaScript, and I think it does a really excellent job of it:
https://leopardjs.com/
You can paste a link to a Scratch URL into the page and it automatically translates it to equivalent JavaScript that can then be edited in the browser or downloaded and edited locally. It's got an impressive and intuitive library behind it and I think it's fantastic.
My lad has been learning Python in Replit. It looks like they are trying to introduce community feedback loops.
For making games, Roblox is perhaps a good choice. You can post a modded example game and get your friends playing it very quickly, then iterate rapidly.
We find a lot of schools go straight to python coding after scratch, but our block based system is a powerful and allows students to write their first lines of Javascript inside the blocks themselves - and they can then go all the way to writing full Javascript files inside Construct 3.
There is a big gap here and after speaking to a lot of teachers it's a big problem and we're hoping Construct 3 helps smooth this gap out for both the students and the teachers.
This is cool, it reminds me of a program I used to use from Corel called Click n Create. Definitely got me into coding so I like the direction you’re heading!
Another student in the lab I'm in has been working on something [0] to bridge between a Snap!-like environment (so, very similar to Scratch) to Python, complete with retaining the concept of sprites having separate code with event handlers and using blocks they'll recognize for sniplets they can drag in to get code that implements the same functionality. I believe it also allows importing of projects made with blocks. It's still very WIP but we're hoping it helps students smooth the transition from blocks.
This happened with my niece. She loved playing with scratch and took classes and then just got dropped at the end when her tutor got a regular job, she asked me how to use python for real and then immediately quit.
She learned scratch and was told it was "coding". This was a massive lie.
One of the coolest things about scratch that I've seen from using it and being an instructor is that it teaches the user how to work in event based systems. I've seen children with better intuitions for event based architectures than some veteran developers.
When launched the community made me laugh. Every lang has its own community, this one is hilarious. They can code but dont bother a 12 year old with your doctrine of copyright. I MADE THIS!
We definitely moved on faster than that back in the 80's. We started with LOGO (which some people know as Turtle Graphics) and BASIC, but pretty much immediately went into other historical languages (prolog, pascal, cobol) and then to C, within a single semester. And through all that, we were always presented with the binary code (in Hex) so we were fully aware of how registers and boolean math worked.
The annual variation shown in the graph immediately says tells me that a large portion of use is driven by academic forces. That can be a problem, but can also be an opportunity.
If the institutions driving Scratch adoption decide to switch away from Scratch, the community will be on much more unstable foundations. The opportunity here is finding non-education modes of engagement. Social engagements, viral engagements, or non-academic partnerships are all ways Scratch could strengthen its community.
Wishing them luck - it looks like this brings joy to a lot of kids.
There is an integrated Minecraft 'Scratch' code editor now (https://minecraft.makecode.com/#editor) although that is probably targeting middle-schoolers. In my experience most teenagers coding for MC (not driven by academic forces) are just using Java directly.
Having already known how to code, I gave Scratch a shot after hearing about it. I know I'm not the target audience, but despite "looking" friendly I found it very complex and not very intuitive at all. If the goal is to ultimately learn programming with industry standard tools, I think the time would be better spent learning those tools and fundamentals rather than becoming comfortable with Scratch and trying to transition to them.
It is definitely a hard switch to make when you're used to being able to just _write_ what you want, rather than having to go look for the block and drag it into place. :)
> If the goal is to ultimately learn programming with industry standard tools
It has variables, if, else, different kinds of loops, event handlers... Of course it still isn't "real" programming, but it does teach some basic concepts of it, while still being relatively easy for a child to use.
I found the same. Then I watched kids using it by following instruction sheets, picking up the concepts, tweaking, making their own projects, and moving on to Python.
I got to understand Scratch by learning how kids use it. It’s just a mindset and expectation shift that is similar to that I experience when learning anything new. When I first learned a proper functional language after years of imperative. When I used a game dev environment that does lots for you.
I never find the time to dive into it, but for years I carry the thought that somewhere in the general direction of “take the visual programming module of Scratch and make it talk to a cleanly designed high-level API of our business application” lies the key for tremendous feature development productivity, at least for some kinds of features — where from then on, our Product Managers simply go like “oh I know, let’s just put this block into that IF block and thus add another step to the user registration”, without the need to use precious dev resources.
Same as it did 10 years ago. Same as IBM's garbage in the 90s. Only difference now is the IDE is both prettier and slower, there's more testing, and there's way more interfaces.
The solution to the problem never got better, it just got prettier. Oh, and the problem just got harder.
The visual block design of Scratch could be directly applied to any programming language AST. And the programming model involving independent "characters" each running its own logic could translate directly to a model of distributed systems.
As a former computing teacher, I loved Scratch. I remember reading about it on a Thursday evening on Slashdot, maybe spring of '08, or 09.
I had a free lesson first thing the next day, so I installed it on the network then had a class of 10 year olds give it a whirl. Had a full scheme of work written by the Monday, and was demoing it to other schools by the summer.
Loved it, loved the scratch board addon hardware, loved the complimentary "makey makey" project, and the cards, and the books and on and on.
Not op but maybe compensation and everything else outside of teaching?
I used to teach computers/math to 8th graders and while teaching is beautiful school politics, terrible benefits, dealing with patents, among others things made the job of teaching incredibly difficult and draining
Burn out. Teaching is a job that is never "done", and expectations from management and parents are constantly set higher and higher. Especially around IT. I lost count of the number of times I asked for help from management and got told "but you are so good at computers".
Tried the startup thing, my product crashed and burned, work for a charity now.
Is there a reason that visual programming languages haven’t taken off for professional programming?
I know of several for specific fields (Dark for backends, TouchDesigner for live graphics/multimedia), but none that are more generalised, open, or in wide use.
It feels like an underdeveloped area that’s ripe for exploration and experimentation.
Probably it's just a hard problem. Max for Live is a bit more general purpose than TD but still has its limitations I'd imagine.
Enso lang is the best attempt I've seen for this: https://enso.org/
I teach Scratch to kids professionally. I love it as a learning tool, but when I need to actually write Scratch code myself for whatever reason, I find the experience pretty aggravating. Finding the block I need from the big list and dragging it into place takes a lot more time than just typing the command.
Scratch programs also become messy quickly as the complexity increases. Normal code is more compact and easier to actually follow.
We tried it the other way. I worked for a decade at Logo Computer Systems, where the principal designer of Scratch used to work. Eventually schools tired of teaching kids text-based coding.
Normal code that's compact and easy to follow is usually that way because it was written by somebody with a lot of experience. I've seen plenty of shit-piles called "code".
There are better and worse programs in every language, including Scratch. However, Scratch blocks physically take up more pixels on screen, so you can't see as much information at once.
Also, in most languages, you don't have to worry about the two-dimensional layout of your code.
I work with a similar platform called NetsBlox which is based on Snap! (sort of Scratch + Scheme) and there's some text-based search/input functionality, to the point where you can write a decent amount of it without your mouse at all. Might be worth looking into, Snap! has a lot of more advanced CS concepts Scratch doesn't AFAIK without making the skill floor noticably higher. It also focuses on creating custom blocks, which makes organization a lot easier.
> Is there a reason that visual programming languages haven’t taken off for professional programming?
Programming languages in common use are way too general to really benefit from a structural editing workflow as seen in Scratch. Meanwhile, other VPL's cannot naturally express the kinds of abstractions that turn out to be critical when programming "in the large", as often happens in professional settings.
It has seen a lot usage embedded in different tools but just isn’t a good fit for a general purpose language. It actually becomes much more difficult to manage as programs get larger. I’ve tried many of these tools over the past two decades and some are fine for what they are but none left me with hope or interest in seeing it replace the dominant paradigm in general.
I sometimes wonder if they could be useful for an OS shell, striking a balance between the extensibility of a text-based shell and the discoverability of GUIs. I mean, combined with search/autocompletion, they're really just a slightly more rigid and structured version of text snippets.
It's a great question. TouchDesigner and similar programs have a limited number of data types even though touch designer does a great job at being a little more general than other programs. Also TouchDesigner and Houdini both have shader languages that allow someone to make nodes that do general purpose array transformations which ups their utility a lot.
One big aspect is handling state. Connecting nodes without side effects is great when each frame is a cycle and all you have to do is transform data into a final result. When actual state is involved it becomes hacky or impossible to do in with only transformations. Other similar hurdles are branching and IO.
The other is having general purpose programming underneath. Shader languages enable a lot, but using a real programming language like C++ somewhere not only opens the door to whatever you need, but allows you to integrate all the libraries already made as well as call out to OS IO APIs etc.
It is amazing though how nice it is to work with an integrated and fluid environment where iterations are updated in real time and errors are narrowed down for you, not to mention profiling broken down by node.
Speed and scalability. Both problems are solvable, and I haven't seen anybody putting the investment to solve it in a grand scale on a popular, open source visual programming language.
For speed: it's really hard to beat the speed of data entry via keyboard. A well-designed set of keyboard accelerators would cover a lot of ground on making visual programming languages comparable to keyboard programming speed, but I haven't seen anybody pull it off yet.
For scalability, and in the sense I mean scalability of project complexity from a toy desktop project to a distributed system deployment or a low level embedded system: the vast bulk of tools that are available for supporting large projects are built around text and the fact that it's relatively easy to translate a tool working in one text-based language to another text-based language. Git doesn't care what language you're using; it's all text. Diffing tools don't care what language you're using; they diff lines of text. As tools like Copilot grow, they will start by disproportionately giving a power boost to text-based languages because they are built to work with text-based languages.
Anything that's going to work with a visual programming language in a way that is as robust as these tools do needs to treat the language as an abstract syntax tree, not a collection of lines separated by line breaks. And the tools to do that are going to have to be written almost from scratch; it's simply an underdeveloped ecosystem because there's so much fungibility between different text-based languages in terms of allowing tools that work on one to work on another.
Do you know vvvv gamma?
It's a visual programming environment for .Net. Its language (called VL) combines dataflow programming with features known from object-oriented and functional programming.
As someone currently employed to port an absolutely gargantuan (~10,000 vi) LabVIEW project to C#, there are very good reasons to not use visual programming languages.
1. Writing it is a pain. This is a minor gripe, comparably, but if you already know what you want it is very, very hard to beat just typing out a word. Dragging and dropping through menus makes every little action take too long for comfort. You also miss out on the syntactic sugar that makes coding so much more bearable: little, everyday things, like indexing into an array, or incrementing a value, end up taking just as long as putting in any other function.
2. The information density is atrociously low. Intuitively, it seems like the opposite should be true, after all, in a real programming language you're missing out on pictures and icons and a whole dimension of space. But it turns out that the whole "function reads top-to-bottom" thing packs a lot of flow information.
3. Flow-based value passing robs you of variable naming. In a language like LabVIEW, you very rarely use typed out variable names. Most are replaced by unnamed wires. This subtle feature strips the program of a lot of contextual information, making it hard to read.
4. Linting. If you thought making consistent, presentable code is hard in 1D space, in 2D it's basically intractable. The amount of time I spend futzing with wire pathing is infuriating.
If there is any chance that a project will require software developers some day (if you're starting a business, or inventing something novel, it will) just bite the bullet and use a real programming language. Visual programming just attempts to make the easiest part of programming easier, and makes everything else more painful in the process.
I used LabVIEW quite extensively in a past job, and eventually switched to Visual Basic. The stuff I was doing didn't need the performance of LV.
I found graphical programming to be physically debilitating due to eyestrain and wrist fatigue. Granted, this affects each person differently, and I also don't use CAD for the same reason. I can type text with my eyes closed, or while I shift my visual focus away from the screen.
I think a reason why LV programs always seem so unreadable is that the sheer physical effort to clean them up gets the best of the people doing the programming.
A general issue with graphical programming is that you're responsible for the developer interface, and really sweating the details to make it tolerably ergonomic is phenomenally costly in time and effort -- think of how many programmers are employed by Apple or Microsoft.
In contrast, when experimenting with a new or improved text based language, you can piggyback off of existing IDE's or even basic text editors, and get a running head start on adoption by a user community. And the economics are such that languages and IDEs can be supported as open source projects.
There are text based dataflow programming langauges, and I think if LV adopted one of them as an option, folks would stop using the graphical environment after getting over the initial hump of learning to program.
Darklang is getting there. Functionality is limited, but feels great to use. Speaking as someone with 15 years experience. Can't wait for it to mature.
A further issue is that if one uses modules/functions, one ends up w/ just a textual description of the algorithm trapped w/in a series of connected/nested blocks.
I prefer to work this way, but I've crashed-burned hard on installation/usage w/ more tools than I can recall off the top of my head (pyFlow, Ryven, GraphSCAD, clikscad, &c.) --- currently I'm just using BlockSCAD and pasting the code into OpenSCAD/RapCAD. I hope that Nodezator (node programming tool done w/ pygame) will work out, but I'm waiting for it to have branches and loops.
> Most importantly, browsing projects shows you what’s possible. A kid begins by playing games, starts to get curious, and next thing you know, they’re changing the code to give themselves extra lives.
This is actually the driver for a lot of kids to learn programming. Neopets and Myspace allowed you to customize your profile with HTML, Minecraft allows you to make mods in Java, Roblox has an entire game studio that leverages Lua. Kids see something they want to be able to do, and they do it!
The steepness of the learning curve does matter, but searching "how to make a roblox game" into YouTube goes quite a long ways these days
Maybe one of the reasons for sudden increase in the projects are companies such as Whitehat Jr. Whitehat incorporates and leverages Scratch in their lesson plans. For each lesson kids may be creating 1-3 Scratch programs. You can read more about Whitehat Jr, their approach to sales etc by doing a little googling. And am sure there are other companies who follow the same practice of leveraging Scratch in tutorials. (edit) Not condoning this, just adding more information.
I remember introducing a middle schooler to programming using Scratch at my highschool's open day. I had spent a few hours making a simple two player shooting game and a maze generator for the IT class display. Most kids just wanted to play the games, but seeing just one of them be genuinely excited about the possibility of creating his own interactive experiences, asking questions about how certain mechanics were implemented, what I did to get to this point, if I thought he would be able to create similar things, was really encouraging. Probably didn't make a difference in the long run, but still a treasured memory for me.
I didn't see anyone else mention it, but I think one contributing factor is the inclusion of Scratch on the Raspberry Pi, which until the past year or so has been one of the most affordable ways to get kids set up with a little computer for learning.
Many educational programs have a setup where each kid gets a Pi (well until recently since the past year they've been hard to get), and Scratch was the perfect companion since it didn't require a ton of RAM or a fast CPU to run well.
At this point though I see it come with a lot of other educational programs on Chromebooks, too. Since the sharing is over that MIT site, it's perfect for those "lite" computers that don't store anything local.
One interesting side effect of its popularity is that I've seen a number of kids who "know scratch" but don't really "program" anything with it. They just load up other people's programs and game with it, basically a Steam for Kids.
JavaScript? I have written things on my phone before though it's kinda a pain. (https://jsconsole.com/ is your friend.) The Scratch editor doesn't work on phones really at all though it's fine on tablets.
305 comments
[ 3.5 ms ] story [ 369 ms ] threadFor me, it was a perfect introduction, because there was an already written, already playable program, and I could dive into the code little by little and explore.
Scratch is very similar. My kids love to play games on Scratch, but they also enjoy taking a look under the hood to see if there's something simple they can modify.
Modern software, by contrast, is usually too opaque - even free software! The barrier to entry is way too high.
My favourite game from a modding perspective is Kerbal Space Program. Just drop a Mono/.NET DLL into its GameData folder and you're good to go, and code completion works automatically during development as long as you have Squad's own DLLs in the right paths.
There's also been technology developed that lets you easily modify specific parts of a method in the game, so you can e.g. insert calls to your own functions at runtime.[1] This saves from you having to modify the game jar itself.
[1]: https://github.com/SpongePowered/Mixin
I remember doing the exact same thing in grade school with Gorillas and QBASIC. I actually want to download it now and play it again.
She loved, and still does love, drawing her own sprites and recording sound effects to create interactive stories.
The Internet Archive has these games available to play by the way:
https://archive.org/details/NibblesQbasic
https://archive.org/details/GorillasQbasic
I think in a way it’s a shame that kids now first see visuals rather than code.
There’s something much more thrilling about seeing a bunch of written instructions become a game, than some sprites that already look a lot like the game start moving about.
Another awesome QBASIC feature - the help section taught you everything you ever needed to know to learn every feature.
- that looks more like what children are used to in everyday UI
- that is *localized*: in general programming languages are centered on English. Most young children in the world don't speak a word of English (beside "hello, what's your name?" If they had the luck to get English classes in grade school)
Lowers the entry barrier by a lot
I still think it’s more awesome to see just a written sentence that I typed out become something. Once you introduce any form of barrier between that and output, it’s hard for anyone to know what’s really happening behind the scenes to help you.
There’s a beautiful purity to just simple text becoming something awesome.
A lot of the stuff we type out in code is syntax and templates. Like this loop:
Starting out, it’s hard to tell if the program syntax is wrong or if the program logic is wrong (just getting the snippet above to look close to right on HN is a pain :-)). Blockly makes that easier by mistake proofing the syntax so the programmer can focus on the logic, variable names, etc.Also applies to adults somewhat - Monad tutorial vs. just use a few monads and see what they do.
But learning enviroments are typically the more inferior Many-To-One variant, so even if your child isn't confused by RPN, and even if (n-1)/n children aren't confused by RPN, the teacher must clarify it nonetheless for the 1/n student who is (or appears to be) confused, a book writer might have even less options and more constraints.
Basically, education is a very complex human-to-human Serialization-Deserialization problem. Knowledge isn't what's in the books, or the video lectures, or on github, all of those are just on-disk "dead" representations, the result of calling toString() on actual knowledge. Knowledge is all the intricate in-memory data structures built up in all the human brains that are currently living. The problem of teaching is : given a brain, reconstruct some of its internal data structures in another brain with an error not exceeding some threshold.
It's bad enough that you have to serialize the very rich and graph-like patterns in your brain into flat streams (words, pictures,sounds) to transmit it, it gets much worse when you have to do it for multiple brains simultaneously, because each brain parses streams differently. The more brains and\or the less you know about each brain, the worse your teaching performance and the uglier the representations you come up with to transmit your knowledge.
This isn't to say that teaching is easy when it's parent->child, just that (assuming reasonably healthy bond) it's as good as it ever gets. A single receiver who is extremely interested in whatever you have to say and will re-try on error a lot of times to understand it, that's the teaching problem on easy mode.
Soon after that wrote program for deleting other programs. actually useful because we didn't know yet how to delete from DOS.
we were kids left with PC with no instructions at all. Parents were busy.
Now in hindsight I see my first steps were somewhat destructive.
As for the other thing, there was some DOS command I learned that forced an immediate reboot. I realized this could be added to the end of an autoexec.bat and create an endless reboot loop.
Well, I thought this was a funny prank so I edited the file on a display PC at Costco. Came back by it later in the trip and it’s still booting and rebooting.
I look back on that and realize it probably had to be replaced and sent to some other state where some tech either had to troubleshoot it or create a new image all together.
Not the best use of value but it was amusing to exert power over computers at such an early age.
In my 8th grade algebra class in a "portable."
This path of playing a game, wanting to learn more, then getting into computers and coding is actually really common in parts of the world where computers and computer-based educations aren't as wide spread.
I hire a bunch in Latin America, Middle East, etc, and every interview my first question is always "why did you get into software?" and I'd say more than half of people I interview got into coding in one of two ways, either gaming, or building websites. I'm interviewing people who learned to code more than ten years ago, when websites were HTML with some PHP and gamed were much more accessible. I'm not sure what the corresponding path would be these days.
Thanks for bringing back the memories though. I looooved playing gorillas!
Great preparation for a career in software haha
If the graphics are useful training wheels to new programmers of scratch, the same is probably true for the text languages. And from time to time even a super cyclist can find a use for training wheels.
For one thing, a language expressed in a common graphical form could help communicate with non-coder domain experts, quality assurance teams, customers, etc. This is kind of an argument to publish the latin bible in the vulgar argot, less exclusive to the priesthood.
Yeah, Makecode Arcade has a similar UI with mappings to and from both Python and Javascript.
https://arcade.makecode.com/
They took the basic idea of Scratch, then made it into more of a game with levels, each level being a puzzle to (implicitly) teach or test programming concepts. As you progressed it'd introduce new syntax, while slowly "fading" more familiar syntax towards actual JavaScript code (though retaining the block/GUI-based interface).
We did some more work on further iterations but I'm not sure what became of it all.
So, for. example, since Scratch. and a text-based language with similar structures (Python, say), are 'essentially' the same, the graphical elements. of Scratch are just sugar, or fluff, and should be ignored.
It's the same mindset that says since anybody can get an FTP account, mount it locally with curlftpfs, and then use SVN or CVS on the mounted filesystem to version control it, there's no need for such a thing as DropBox.
Advice for the terminally reductionist-minded: Maybe the things that make Scratch different from Python are actually the most interesting thing about Scratch.
Kudos to the scratch team.
A bunch of my peers where using the visual editor, but I took the plunge and learned NQC to do my programming. Having multiple paths available to users helped the platform and broadened its accessibility.
I'll never forget the instructor teaching me to always make sure my curly-braces matched up. :)
https://www.scratchfoundation.org/scratch-conference
That "Hacking apps with Makey Makey & Scratch" session looks particularly interesting.
https://easylang.online/ide/
Where the trace shows, it would be even better if the variables could be edited, which brings it even closer to debugging, and also expands on how the program logic works.
For beginning programmers, memorizing syntax is a major source of cognitive load. As a result, it's harder for them to practice the computational thinking skills that coding is really about. Scratch removes this barrier.
I actually think Scratch is a good tool for beginners of any age, including adults.
https://turtlespaces.org/weblogo/
It's very, very difficult to do things as simple as display a number on screen. My 7yo was making a number guessing game, and to display a two-digit number we had to make two sprites that had 10 "costumes" (0-9) then do modular math to select the costume for each digit. Sprites also have their own code, and if you duplicate one and edit the code the edits don't apply to the duplicate - so there's no user library or abstraction power at all.
This made dealing with Scratch far more complex and time-consuming than the logic of the game my kid was making, which is the exact opposite of what you want in a learning environment. I don't really want to focus on the idiosyncrasies of Scratch when teaching programming.
Some simple text and drawing commands, user-defined functions, and a library would go a huge way towards making Scratch simpler. There are some other Blockly-based environments that may have this... but they're not as popular.
I suppose I might be missing something, but if you just care about displaying the number, rather than any particular styling, you can just show the variable, right?
There is also a command block to show or hide it dynamically.
So if your kid is cool with this kind of clever workaround for the limitations of some piece of crap, you have a future software engineer.
I’ve an anecdote of my own that I still think about semi-regularly:
I was volunteering at a school for a year or so helping them teach 9-11 year olds Scratch. Most of the kids spent the term trying to move sprites across a canvas and making basic platformer style games. It was a heap of fun while also challenging at times.
One day one of the students grabbed my attention and asked for some help making something work. She’d decided to build a trivia game, and was having an issue working out how to make the text for the previous question disappear. When I looked at what she’d built I was blown away. She’d basically built a fully recursive function in Scratch that would iterate through a collection of questions & answers. It was built almost exactly like I’d expect a professional developer to build something. A simple reusable function. I didn’t teach that. She’d never used Scratch before. She’d not done any programming before. It was just the most intuitive way for her to do it.
Another one: a few months ago I wrote an Awk function which can increment an alphanumeric string, like "A0Z" -> "A1A" -> "A1B" ...
I had to write a BEGIN block which populates global hashes for looking up the successor of a character, and whether it wraps around in its class. By character, I mean string of length 1, of course; there are no characters in Awk.
Constraint begets creativity.
A box needs to be defined in order for one to think outside of it.
Not 100% sure it’s still beginner friendly as I used it over a decade ago, but I’m pretty sure there’s a free trial, so you could find out.
Wat? Really. I thought it just has GML which is one of the shittiest languages I've ever used. It's really and seriously crap. On par with trying to write real programs in sh.
This, imo, is what makes Scratch a great education platform. It has a couple of very easy to use primitives (such as displaying and moving sprites) and leaves you to build whatever else you need by abstracting things on top of it. This teaches you one of the most foundational programming skills: how to do something complicated with only weird, rudimentary tools.
They don’t have time to hack like that anymore.
Actually, the comment in question would have been perfect encouragement in my view just by removing that phrase.
> This made dealing with Scratch far more complex and time-consuming than the logic of the game my kid was making, which is the exact opposite of what you want in a learning environment. I don't really want to focus on the idiosyncrasies of Scratch when teaching programming.
Printing “Hello World” and displaying a number is easy in languages like Java. Making a top-down shooter is not. So why does one usually do the print stuff rather than the top-down shooter stuff? Ain’t that also because of the idiosyncracies of your run of the mill general purpose programming languages?
I tried to do a different guessing game, not much more complicated, but it does get hard... I wrote up some thoughts in a thread: https://twitter.com/ianbicking/status/1546207554665172992
It's good that Scratch doesn't change that much, there's lots of books and traded wisdom that retains its value as a result, but there's also some big missing pieces that make some things very hard to write in Scratch, and they could be improved upon but they aren't
Even with that feature, there is no "UI" capability. Getting stuff on the screen still consists of putting up sprites with words over their heads! I ran into this while developing two games on the platform, like this one: Mathtown Alley[0]. It's a crippling limitation even for me, and I write TS professionally.
[0] https://arcade.makecode.com/59845-44370-91548-60605
With Scratch you are given a limited set of blocks that are designed for a limited set of solutions. It is at the same time not particularly powerful nor does it feel like you can grow your solutions to anything you have in mind.
I have three kids and have taught (or attempted to teach) each of them programming. I started with Scratch every time, but it never piqued their interest, although they understood it. I have since started them on Javascript from the very basics (Khan academy) and they are very curious about each new lesson and the weird powers it brings. YMMV but people should not assume Scratch or Mindstorms and so on are necessarily better learning environments, just because they are 'friendly' - it can be quite the contrary.
Natural developers like myself and plenty of others spent our childhoods hunched over a zx81/spectrum/commodore/whatever because we thought it was _cool_.
Scratch has different constraints than most languages, but I don't view that as a bad thing. Scratch takes what is normally a huge undertaking--sprites--and makes them as much a first-class primitive as stdin/stdout are in most languages. Yeah, this makes the number-guessing and text-adventure games we usually use as teaching projects harder, but it makes it a lot quicker to build visual games. I don't think Scratch needs to change, I think we need to recognize that kids in this generation won't be building the same starter projects that we did growing up.
The sound generator was quite rad too. 3-voice chords. Sines, triangle, etc waveforms.
My 12 year old self liked it a lot.
I sat down with him for about an hour and I printed a "cheat sheet" for the various arithmetic operators (just the basic ones) and he's now quite able to just whack a simple script together and execute it on the command line.
Having said that, he wasn't entering the situation completely blind. He's been using a PC with Linux (Ubuntu) since he was 3 years old. He's been playing Minecraft for 4 years (which is excellent for younger kids to learn mouse skills).
I also started him out on GCompris on a laptop. Then we both built a PC for him when he was 5. I got a load of cheap second parts during the early part of the pandemic and I let him do it himself (while observing and guiding).
I started him early because I started early too and I started him off on PHP because I remember it being relatively easy to learn when I was a kid because it isn't a particularly strict language which means a young mind doesn't have to perform a huge amount of translation in their own head, they can almost type exactly what they're thinking and run it.
The command line I introduced almost immediately. It was a way easier method of teaching him to launch apps without my help...I just set the terminal to load on startup and printed him another "cheatsheet" of basic stuff that he needed (no rm -rf * just yet).
If he's in an exploratory mood he will use the menus and UI but if he just wants to get straight into Minecraft or write a script he can just get stuck in!
I can see scratch becoming more interesting to him further down the line but for now, certain things are easy enough.
Typing is an interesting one though...I spent a fair bit of time working on his typing because his handwriting at school wasn't up to par (he's fine now, but his crap handwriting was holding his spelling back a bit). As soon as he became somewhat proficient at typing his spelling improved no end. Unfortunately though, his teacher won't let him do spelling tests on a laptop. Which I think in 2022 is the dumbest thing ever. They've only just started teaching typing and basic computer skills in his class (as of about 6 mo this ago). I had his teacher take me aside and ask me exactly what the hell I did to get him so far ahead. They measured his typing speed at 60wpm!
This all said though, I am an IT guy...so parents with little to no tech skills might not have the smooth ride I had, which is probably where tools like scratch come in...I think it's a tool for non-technical parents as well as kids.
Before scratch though, I'd highly recommend GCompris...but be warned, you need to do it short sessions (20 minutes or so) because kids get bored of it fast.
My youngest is 3 and he's getting second knowledge from my oldest right now as well as the same stuff I did with my oldest...so maybe he'll learn even quicker?? We'll have to wait and see.
https://www.nytimes.com/2019/05/30/well/live/surgeons-hobbie...
Producing text and formatting strings is likely deemed out of scope for that reason. People figuring out clever workarounds is a bonus!
1: https://edutechwiki.unige.ch/en/Microworld
edit: better link
I still think Scratch’s interactive environment is impressive.
I think there's a lot of meat on the bones of creating tools that make it structurally impossible to write statically invalid programs. Consider how much time the average developer consumes in a simple iterative process of writing a program, discovering they have made a simple syntax error, and correcting it. IDEs have come a long way in shortening that loop by providing interactive feedback that the current program is invalid, but if the static analysis rules of the language move all the way into the development tooling, you're compiler doesn't even need a static analysis step!
I find this sad, as it means a lot of people who might otherwise benefit from programming in their daily lives never pick it up again. Just as not everyone who can cook needs to be a chef with professional grade equipment to benefit from the activity, not everyone who programs needs to be a software developer with all the incidental complexity that entails.
We start teaching Java to kids as early as 8th/9th grade when the vast majority aren’t ready for it. Even my sophomore students in college regularly struggle with the language.
There’s a huge gap between scratch and Java that is begging to be filled by innovative language design. Or better yet, a language that can a student can stick with from early age all the way through adulthood. Imagine if students who started at 11 actually stuck with it through 18 and beyond, instead of giving up at 13/14. Scratch has a perception problem as being something exclusively for kids; I don’t know how it can shed that reputation.
We need to stop treating early childhood programming education as the first stage of the funnel into corporate tech jobs. Not everyone wants to end up there, and we shouldn’t design their education with that goal in mind. Programming literacy is too important in the 21st century to reserve the skill for would-be devs.
Good question, I personally think p5.js is a great option. JS is very flexible, and the live environment (at editor.p5js.org) is I suppose very similar to scratch. Drawing elements like squares and circles is as simple as square(), circle(), etc. (with parameters). It's very easy to share an publish (could be on github[1], or just link directly from the editor!). Highly recommended for beginners and any quick interactive work really.
It would be great to have a community page like Scratch though.
[1] See a little procedural tree: https://gustavo-nramires.github.io/ :)
https://snap.berkeley.edu/
And yes, I find the exclamation point annoying.
* Processing
* Love2D
* Unity / Godot
* Pygame
In the past, Flash filled this niche, I think (although I never programmed in it). Looking at my own list above, and others' responses, I don't think this niche has truly been filled, alas.
Maybe a startup idea?
I work at a company that runs coding classes for children.
We created https://woofjs.com/ explicitly for the purpose of transitioning students from Scratch to a text based language. It's not perfect, but worth a look!
Minecraft and Roblox support mods written in Java and Lua respectively but it's a pretty big leap from Scratch to Minecraft mods.
I was recently discovered a dedicated editor for Minecraft modding (https://bridge-core.app) and that seems pretty cool. A lot more could be done in this space though.
You can paste a link to a Scratch URL into the page and it automatically translates it to equivalent JavaScript that can then be edited in the browser or downloaded and edited locally. It's got an impressive and intuitive library behind it and I think it's fantastic.
For making games, Roblox is perhaps a good choice. You can post a modded example game and get your friends playing it very quickly, then iterate rapidly.
It's a text based programming platform centred around creating games and can be used from a young age and into adulthood.
We find a lot of schools go straight to python coding after scratch, but our block based system is a powerful and allows students to write their first lines of Javascript inside the blocks themselves - and they can then go all the way to writing full Javascript files inside Construct 3.
There is a big gap here and after speaking to a lot of teachers it's a big problem and we're hoping Construct 3 helps smooth this gap out for both the students and the teachers.
[0] https://github.com/dragazo/PyBlox
Sadly, they often move on to real computing. They are taught how to use Word and Excel.
I think python is also a great candidate.
She learned scratch and was told it was "coding". This was a massive lie.
If the institutions driving Scratch adoption decide to switch away from Scratch, the community will be on much more unstable foundations. The opportunity here is finding non-education modes of engagement. Social engagements, viral engagements, or non-academic partnerships are all ways Scratch could strengthen its community.
Wishing them luck - it looks like this brings joy to a lot of kids.
> If the goal is to ultimately learn programming with industry standard tools
It has variables, if, else, different kinds of loops, event handlers... Of course it still isn't "real" programming, but it does teach some basic concepts of it, while still being relatively easy for a child to use.
I got to understand Scratch by learning how kids use it. It’s just a mindset and expectation shift that is similar to that I experience when learning anything new. When I first learned a proper functional language after years of imperative. When I used a game dev environment that does lots for you.
The solution to the problem never got better, it just got prettier. Oh, and the problem just got harder.
I had a free lesson first thing the next day, so I installed it on the network then had a class of 10 year olds give it a whirl. Had a full scheme of work written by the Monday, and was demoing it to other schools by the summer.
Loved it, loved the scratch board addon hardware, loved the complimentary "makey makey" project, and the cards, and the books and on and on.
incredible project.
Why former?
I used to teach computers/math to 8th graders and while teaching is beautiful school politics, terrible benefits, dealing with patents, among others things made the job of teaching incredibly difficult and draining
Tried the startup thing, my product crashed and burned, work for a charity now.
I know of several for specific fields (Dark for backends, TouchDesigner for live graphics/multimedia), but none that are more generalised, open, or in wide use.
It feels like an underdeveloped area that’s ripe for exploration and experimentation.
Scratch programs also become messy quickly as the complexity increases. Normal code is more compact and easier to actually follow.
Also, in most languages, you don't have to worry about the two-dimensional layout of your code.
I bet most people saw your comment and thought of things like befunge [0] (and scratch of course), but I smiled when I thought of fortran 77...
[0] https://en.m.wikipedia.org/wiki/Befunge
Programming languages in common use are way too general to really benefit from a structural editing workflow as seen in Scratch. Meanwhile, other VPL's cannot naturally express the kinds of abstractions that turn out to be critical when programming "in the large", as often happens in professional settings.
One big aspect is handling state. Connecting nodes without side effects is great when each frame is a cycle and all you have to do is transform data into a final result. When actual state is involved it becomes hacky or impossible to do in with only transformations. Other similar hurdles are branching and IO.
The other is having general purpose programming underneath. Shader languages enable a lot, but using a real programming language like C++ somewhere not only opens the door to whatever you need, but allows you to integrate all the libraries already made as well as call out to OS IO APIs etc.
It is amazing though how nice it is to work with an integrated and fluid environment where iterations are updated in real time and errors are narrowed down for you, not to mention profiling broken down by node.
For speed: it's really hard to beat the speed of data entry via keyboard. A well-designed set of keyboard accelerators would cover a lot of ground on making visual programming languages comparable to keyboard programming speed, but I haven't seen anybody pull it off yet.
For scalability, and in the sense I mean scalability of project complexity from a toy desktop project to a distributed system deployment or a low level embedded system: the vast bulk of tools that are available for supporting large projects are built around text and the fact that it's relatively easy to translate a tool working in one text-based language to another text-based language. Git doesn't care what language you're using; it's all text. Diffing tools don't care what language you're using; they diff lines of text. As tools like Copilot grow, they will start by disproportionately giving a power boost to text-based languages because they are built to work with text-based languages.
Anything that's going to work with a visual programming language in a way that is as robust as these tools do needs to treat the language as an abstract syntax tree, not a collection of lines separated by line breaks. And the tools to do that are going to have to be written almost from scratch; it's simply an underdeveloped ecosystem because there's so much fungibility between different text-based languages in terms of allowing tools that work on one to work on another.
For serverless functions/API pipelines, check out (formerly Integromat): https://www.make.com/en
Some even use it for procedural modeling ! (Houdini, Blender)
Do you know vvvv gamma? It's a visual programming environment for .Net. Its language (called VL) combines dataflow programming with features known from object-oriented and functional programming.
https://visualprogramming.net https://thegraybook.vvvv.org
1. Writing it is a pain. This is a minor gripe, comparably, but if you already know what you want it is very, very hard to beat just typing out a word. Dragging and dropping through menus makes every little action take too long for comfort. You also miss out on the syntactic sugar that makes coding so much more bearable: little, everyday things, like indexing into an array, or incrementing a value, end up taking just as long as putting in any other function.
2. The information density is atrociously low. Intuitively, it seems like the opposite should be true, after all, in a real programming language you're missing out on pictures and icons and a whole dimension of space. But it turns out that the whole "function reads top-to-bottom" thing packs a lot of flow information.
3. Flow-based value passing robs you of variable naming. In a language like LabVIEW, you very rarely use typed out variable names. Most are replaced by unnamed wires. This subtle feature strips the program of a lot of contextual information, making it hard to read.
4. Linting. If you thought making consistent, presentable code is hard in 1D space, in 2D it's basically intractable. The amount of time I spend futzing with wire pathing is infuriating.
If there is any chance that a project will require software developers some day (if you're starting a business, or inventing something novel, it will) just bite the bullet and use a real programming language. Visual programming just attempts to make the easiest part of programming easier, and makes everything else more painful in the process.
I found graphical programming to be physically debilitating due to eyestrain and wrist fatigue. Granted, this affects each person differently, and I also don't use CAD for the same reason. I can type text with my eyes closed, or while I shift my visual focus away from the screen.
I think a reason why LV programs always seem so unreadable is that the sheer physical effort to clean them up gets the best of the people doing the programming.
A general issue with graphical programming is that you're responsible for the developer interface, and really sweating the details to make it tolerably ergonomic is phenomenally costly in time and effort -- think of how many programmers are employed by Apple or Microsoft.
In contrast, when experimenting with a new or improved text based language, you can piggyback off of existing IDE's or even basic text editors, and get a running head start on adoption by a user community. And the economics are such that languages and IDEs can be supported as open source projects.
There are text based dataflow programming langauges, and I think if LV adopted one of them as an option, folks would stop using the graphical environment after getting over the initial hump of learning to program.
I always show people this:
https://www.ni.com/docs/en-US/bundle/labview/page/gmath/nonl...
There are some systems which try to make it just a straight-forward description --- Drakon Editor comes to mind.
Scalability is an issue --- but screens are larger these days, so may be more workable (I've managed some decently complex models in BlockSCAD:
https://www.blockscad3d.com/community/projects/1385418
A further issue is that if one uses modules/functions, one ends up w/ just a textual description of the algorithm trapped w/in a series of connected/nested blocks.
I prefer to work this way, but I've crashed-burned hard on installation/usage w/ more tools than I can recall off the top of my head (pyFlow, Ryven, GraphSCAD, clikscad, &c.) --- currently I'm just using BlockSCAD and pasting the code into OpenSCAD/RapCAD. I hope that Nodezator (node programming tool done w/ pygame) will work out, but I'm waiting for it to have branches and loops.
This is actually the driver for a lot of kids to learn programming. Neopets and Myspace allowed you to customize your profile with HTML, Minecraft allows you to make mods in Java, Roblox has an entire game studio that leverages Lua. Kids see something they want to be able to do, and they do it!
The steepness of the learning curve does matter, but searching "how to make a roblox game" into YouTube goes quite a long ways these days
GitHub only reached 100m repos in 2018[2] - I can't find any more up-to-date numbers, but it's probably around 150m today.
It's crazy to think that Scratch and GitHub operate on similar orders of magnitude.
[1] https://scratch.mit.edu/statistics/
[2] https://github.blog/2018-11-08-100m-repos/
Many educational programs have a setup where each kid gets a Pi (well until recently since the past year they've been hard to get), and Scratch was the perfect companion since it didn't require a ton of RAM or a fast CPU to run well.
At this point though I see it come with a lot of other educational programs on Chromebooks, too. Since the sharing is over that MIT site, it's perfect for those "lite" computers that don't store anything local.
One interesting side effect of its popularity is that I've seen a number of kids who "know scratch" but don't really "program" anything with it. They just load up other people's programs and game with it, basically a Steam for Kids.