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.
> 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.
>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.
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.
> 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.
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
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!
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.
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.
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.
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.
This is the coolest thing I have seen this week! Is the program open sourced?
I firmly believe Scratch should be taught at university level for business students. We studied C, C++, VB and MS Access. We didn't understand crap, nor the instructors had any interest in teaching that crap.
Scratch is a wonderful tool for any people to dip their toes in programming. And stuff like this makes me double down on this idea. Scratch should be the first thing to be taught to teach programming regardless of education level. BI tool and database interaction is the perfect and practical application of Scratch.
This was actually built between 2012-2013 - it is quite a tangle of old and rusty (but very reliable) PHP code and IE9-era, 'jQuery-esque' JavaScript. Realistically this can't be usefully made open source (and if it were it would probably have to be rewritten in order to be more generally useful). That said I would be very interested in an open source re-implementation of this using modern techniques!
It is great that Scratch can be used as an introduction to programming, but that is not why it was created. It was part of the MIT MediaLab "Computer Clubhouse"[1] project where it would be used to enable a remix culture of cute animations and even simple games. Scratch's implementer, John Maloney, had already helped create a programming environment for kids called EToys[2] using Squeak Smalltalk, just as in the first versions of Scratch (later rewritten in Flash and then in Javascript).
So the comments about how it is hard to do in Scratch something that would be trivial in Basic or some other language are not surprising. It is an animation system that allows you to use programming to increment that.
As others have pointed out, a system with the same visual as Scratch but design for actually programming is Snap![3] so it is just a matter of using the tools for what they were created to do.
I enjoy using stuff for things they were not created for. In my HN profile I claim to be a hacker in the old sense of the word, and this is a big part of old style hacking.
But I am not then surprised when it takes a lot more effort than using something that had been created for that would take. For example, in 1983 I wrote a fancy Logo implementation using TI99/4A Extended Basic. It was far more complicated than the implementation I wrote in C. But the Basic version actually ran while the C version was just on paper since I didn't have access to any computers with C at the time.
I think it is great that people end up doing in Scratch things that you would expect would need Python or something like that. But if some 5 line Python program becomes a monster in Scratch, that is to be expected. The opposite is also true: a 5 line Scratch program might take pages of Python to replicate.
I’m not really sure what you’re pushing back against here — are you taking issue with the terminology? Or are you saying that scratch should not be used as an intro to programming logic because it was originally designed to control visual components fairly superficially?
He’s explaining the origins of why it’s bad at certain things: because it wasn’t originally designed as a general purpose tool. That’s the whole point of his comment, nothing else is implied
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.
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.
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.
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.
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…
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.
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 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.
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.
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.
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'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.
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.
In a way it's very disappointing that such a difficult to program system has become the default tool for teaching kids to program.
Also a shout out to CodeCombat - that's also a great way to teach kids very advanced underlying programming concepts whilst completely hiding all the complexity.
I'm one of the founders of Construct 3 - thanks for mentioning us! We see that after scratch lots of schools go straight to coding raw python, we feel Construct 3 can more naturally provide the transition from Scratch to coding and are having a lot of success in schools for this reason.
Construct 3 allows you to write Javascript files, but also uniquely write lines of Javascript into event blocks so you get to write your first lines of Javascript in a more familiar environment.
Construct3 isn't just for kids - it's capable of making "real" games.
I did a little fun coding on it and it's really great - I recommend Construct3 to anyone wanting to make a simple game with kids or a sophisticated game.
Construct 3 is miles ahead of Scratch - really not even a comparison.
Google Game Builder what I really like to use to teach because it’s using JS. Not that I used it many times but it’s really engaging and at least you interact with a “real” language.
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.
In Scrath you hit language limitations all the time. The Scratch designers say it is so to be friendly to beginners, however the need to invent crazy tricks to achieve simple things is not actually friendly.
IMHO, it is better and simpler to teach children using more normal languages, consisting of a small set of well composable elements.
The Snap! is an extended reimplementation of Scratch, but prvides power approximately equal to Scheme: https://snap.berkeley.edu/
However, I haven't used it much since I need development support on tablet, which is not complete in Snap.
I also tried Lego Boost and Lego Technics - the coding experience is basically the same as in Scratch, but for teaching programming Scratch is better I think, because you can create interesting things without the need to connect to devices. And not much you can build from lego motors and sensors.
And the last I explored was the Castle mobile app. A couple of games I created:
The coding experience is worse then Scratch in my opinion (especially on Android were the Castle app has a redraw bug, so that the menus you invoke are not visible until you manually initiate a redraw by switching to Android app list and back to the Castle app). But the advantage is 2d physics support - they wrap the Box2D engine.
This Scratch thing reminds me of Authorware. Fun and powerful if you are still at a point in life where you are terrified of coding with text. But after you outgrow it you regret not using those brain cells to learn conventional programming. (At least, I did.) I'm not saying it's without value, but I am saying it can lead to disappointment.
One thing to remember is that Scratch can 'kickstart' the learning process.
For kids being able to quickly display graphics and move them around offers a big buzz and gratification very quickly. With a lot of other programming languages the gratification is greatly delayed which can make people quickly abandon them unless they already have some experience in programming.
Not sure I can name another programming language that you could give a 12 year old and they would be able to self-start and would not be likely to abandon learning it if they follow the standard 'get started' guide for the language. Unity is possibly the next closest, although it is much more complex to learn.
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'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 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.
The great: Scratch has some hugely good things going for it. The community sharing model is ridiculously good. The ease of being able to jump in, put up a sprite and make it do something is super. It is so easy to go from kid-style ideas to something that happens on screen: "there is a castle, and a dragon, and it flies over and makes a noise...". They did a great job of making the sprite actors easy to use with a small number of programming blocks. The actor/message model is nice. Importing images and making them into objects is easy, and there is a big enough library of built-in actors to get you started.
The not-so-great: if you try to do something outside of the range of what Scratch really tried to make easy, it quickly gets hard. Moving 2d sprites around in simple patterns using built-in collision detection: peachy. Pretty much anything else: not so much. And as projects get large the block-based visual programming is a frustration. There is no text mode.
My wish: It would be great if someone would make a one-level-up version of scratch, with great community sharing features and sprite/object/message based library with super-easy graphics programming but text-based source code and with the ability for add-on libraries to be part of the ecosytem.
I started something like this for a local hackathon to teach kids programming, but then COVID hit, the hackathon was canceled, and the project stalled.
I think that tools like scratch and code.org really need to expand their ability to interact with 3rd party services. Code.org has a very limited http request API, but it is locked down to a couple APIs (I’ve looked at this feature, and I have… concerns over API key security) while scratch has no such capability. I really think that this type of thing helps ease the transition between block coding and using a written language. I do understand that there are some concerns with abuse, but I think that many of those concerns have effective mitigations.
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.
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.
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.
> 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 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.
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.
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.
> 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!
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!
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.
> 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
> It was the community aspects that really drew in my kids. They would get really excited whenever somebody followed them or “loved” one of their projects. It gave them the motivation to build more ambitious things.
This is really what sparked my love of coding and, more broadly, creating things when I made projects in Scratch as a kid in the early 2010s. Seeing all of the positive feedback on stuff I posted as well as seeing the awesome stuff other people posted motivated me to keep one-upping myself with cooler and cooler projects. Those who downplay the positive effect Scratch can have on kids tend to overlook this part of the equation.
A lot of discussion here about the limitations of Scratch as a programming language.
But the magic of Scratch is the community. My daughter learned Scratch, and she joined multiple teams of 10-year olds making all kind of interactive stories and games. And virtually every interaction she had was positive, uplifting, and helped her construct her identity as a programmer.
She now teaches Scratch for kids and programs in Java and Python. But making those friends and doing those team projects was invaluable - and nearly unreplicable in another language/ environment.
I have trouble understanding how another language is more intuitive than scratch, indeed you don't provide any examples of more child friendly languages, just that it didn't work for your son.... which could just be because your son doesn't wanna program.
I would like a physical version made of blocks that can be arranged rather than dragging boxes on the screen. Not another language as such but I suspect would be more intuitive.
This reminds me of Code-a-piller. It's a toy designed for pre-schoolers, so definitely not a full language, but it's physical and lets you sequence basic instructions in an intuitive way. More here: https://www.youtube.com/watch?v=iYEKD1Befg8
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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/
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.
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.
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.
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.
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.
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.
> 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.
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. :)
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 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.
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.
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.
I learned to program on scratch in the 6th grade when it was very new, circa 2008. In many ways, it is more real than other learning languages.
In retrospect, the smalltalk influence of scratch I think left such an impression on me that I continue to love dynamic, always live environments to this day. The broadcast system is surprisingly powerful and forward thinking. I do recall it being a bit difficult to build up your own abstractions, but such guardrails I think are useful for learning and I usedd Scratch before custom blocks were available.
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
There's a similar project at MIT call App Inventorhttp://www.appinventor.mit.edu/ which uses a graphical Scratch-like environment to build Android apps. I can't tell if the two projects share code, but they certainly share philosophy and approach.
I found App Inventor actually quite a practical way to write small useful Android apps. Certainly better than loading squigabytes of IDE/library/emulator/etc and fighting with the Android build system. (This from someone with plenty of code-cutting history!)
I wouldn't use App Inventor for anything big, but for small projects, have a look.
I love what they've done and how my kids have taken to it. The combination of design tools and code reminds me of the "golden age" of Flash in some ways. Vector graphics editor, sound editor, code, it all works together - this is pretty special to see in one tool that kids can use.
The games are actually getting quite good on the platform, and that means it's hard for a lot of parents to understand how much time is gaming vs. coding.
I've never made the Flash connection but I totally agree.
On my end, I try not to worry too much on the gaming vs coding thing. I'd rather have my kids playing games on Scratch then some other place where they can't view source.
I figure, if they have some basic skills and know what's possible, they'll eventually get curious and poke around. I think that's more true for some kids then others though (even in my own house).
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.
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 awesome! I used it in high school for some small, silly games. It was fun :)
As for "next steps" from Scratch: I think micro:bit [0] can fill that gap. Several of my coworkers were part of an event that used it to teach a group of middle-schoolers about programming. It uses block-based programming (supporting even Scratch I think?) and lets you move to and from a text-based language (Python and JS IIRC). I'm not sure if micro:bit has the same social component that the Scratch site does, but it seems like it could at least kids "hey, this is what my code looks like in Python!" Then, they may go and download Python and start hacking away on that.
The simplicity of the visual language that Scratch provides inherits from the simplicity of Lisp, via Logo. The Logo language (& the Mindstorms pedagogical philosophy), which is what Scratch builds off of in a visual way, was implemented as a dialect of Lisp.
From anecdotal experience, I do believe that the choice of a Lisp for Logo was an important criterion in the simplicity of the language, and thus the high impact of the learning impact.
I do think that if we find Scratch useful and powerful, then we should really re-/consider Clojure as an important language for real general purpose programming work, for many reasons:
https://www.youtube.com/watch?v=Y3-53JoGPE4
My son and I got a lot out of a similar iPad app called Tynker, which we both ended up liking better than Scratch, which he used at school. Tynker has a physics engine, which opens up all sort of great game possibilities (we made a cheapo Angry Birds). Also as referenced above, Tynker has a slightly richer language that gets rid of the need for some bad practices (e.g., functions can return values, you can declare local vars vs all-globals-all-the-time, etc). Having the tool work well on a tablet also travels really well, and is a simpler container than a browser window for a really young kid.
Scratch was how I got started in programming back in elementary school. It was taught in our computer classes. Everything this article says is spot on, the social aspect is amazing. I made a few programs and got comments on it and stars which hooked me. Side note hearing griffpatch is still around amazes me, I remember playing his scratch programs and wishing I could eventually do that. What’s amazing is it’s all still around and runs![1]
Interesting that this popped up now. I had heard of Scratch but never really looked into it, but decided to give it a go last month. I decided to write a planetarium using the actual Hipparcos catalog, and solving Kepler's equation for the planet positions. I had hoped I could use it as an example to show that it's not really that hard to do. Unfortunately, I found it pretty tough to organize the code in any meaningful way. E.g. blocks can't have local variables, nor return values. You can't call a bock in another sprite, there's a workaround using "broadcast and wait", but it triggers a screen refresh. Just moving blocks around to order them in a meaningful way was quite a chore. Some mistakes, like making a variable global rather than sprite level, can't be corrected. Adding comments seems to be a bit buggy, and they don't move as you move the blocks around.
Since I've been programming for many a decades now, it's hard for me to see what it'd be like for a beginner to approach the language. But I was left wondering if this really is any easier for beginners. And if it is easier, is it really better they learn this way since it seems to actively force some poor programming choices.
In the end my code ended up looking way more complicated than it really is, and I'm not sure anyone but me could make heads or tails of it. (For anyone that wants to have a look: https://scratch.mit.edu/projects/708233643/ ).
> Since I've been programming for many a decades now, it's hard for me to see what it'd be like for a beginner to approach the language. But I was left wondering if this really is any easier for beginners.
I teach programming classes for children in both Scratch and Javascript. I can promise Scratch is easier for beginners.
You're absolutely correct that past a certain point of complexity, Scratch becomes kind of stupid. Most kids, however, are not trying to solve Kepler's equation.
If you ever have the urge again, try using Scratch to make a simple game, something like "catch the falling objects" or "avoid the moving obstacles". I think you'll find the process a lot smoother.
I search for anything I can to figure out what is happening with the Scratch community because my daughter, who has been a scratch user for 6 years has, over the last two been on there almost exclusively for the "community."
It's super cool to see other kids remix her works and she to do the same.
The one complaint I have is that we have run into one creep who was soliciting kids' info, however it was only one time and he disappeared pretty quickly.
but I'd really like to see a nice, stand-alone desktop development environment like to Scratch which isn't encumbered by a sandbox and which is able to write and append to local files and which is easily installed and which runs reliably.
Crashed and burned on pyFlow, Ryven, GraphSCAD, and a bunch of others.
Currently hoping that Nodezator (a node programming system based on pygame) will pan out --- it just needs branches and loops for my purposes:
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.
- among many thoughtful comments, a search for "fun" yields mostly comments about functions and expressivity; I think this is a key aspect that isn't as apparent to many experienced people here. The fond recollections of ZX80/81's captures some of that idea, though.
- Scratch is blessedly non-commercial and immensely approachable. It's educational mission is not top-down, but bottom-up.
- The mix of 3GL expressivity with enough constraint to get a person started is great. Kind of reminds me of the generativity I see in kids playing Minecraft.
- The pure old-schoolness of it all keeps you from being mugged in a dark semantic alley by a gang of monad-botherers.
My children did not like scratch (it is taught at school in France). They had much less problems to understand Python which seems more natural in the interactions (displaying things, especially).
They are unfortunately not interested in programming but when they have to do something at school they catch up with Python quickly. With scratch not that much.
Python is a bit more advanced in the sense that it’s a more general purpose and you have to know how to type on the keyboard well enough. I started with basic and logo back in the 80s but if scratch were a thing back then I’d have probably benefitted from it quite a bit. I see scratch as a first ramp into programming for tots and am glad it exists but also hope it won’t become a thing to handicap adoption of other programming languages
I did not mention that my children were early teenagers when they had scratch at school.
I also started with BASIC in the 80's and scratch would probably have helped with some general concepts, especially loops and variables. But in my experience (of two data points :)) it is quickly left on the side for more effective languages (more effective because they can be typed and easily moved around, copied etc.). Vscode hints also help a lot.
It is impossible to do anything substantial in Scratch because it does not have text-based representation, and so cannot be comprehended by programming tools which are critical to modern programming (or even just programmers). If it had a comprehensible ETL language, it might be possible to use for significant engineering, but the current export format is just a JSON morass, worst in some ways than byte code. As usual with ETL hacking of a primarily graphical representation, there could be significant issues where the VUI is unable to represent changes made "behind its back"...all of which is to say, forget it.
I just tried Scratch to make a quick little animation and I must say that it's actually pretty amazing. I've known about it for close to a decade but never really tried it out. I just spent a few minutes playing around and I was amazed by how easy it was to program a simple little animation.
I have to say that I used this back in school many years ago, and I absolutely hated it. But I realize that other people might feel different about it.
I much preferred just being able to write text characters, I felt like it gave me a lot more freedom in what I can achieve, but also how I achieve those things.
I discovered the existence of, and taught myself, BASIC on my Apple IIc when I was about 8. My first program was an implementation of Mad Libs. Surely we could just take that concept and make it even easier for kids.
I used Scratch ALL THE TIME as a kid. I'd always play other people's projects and I made several of my own. I think in the long run it did help me; it was definitely fostered my interest in coding and game dev. And it probably did help me understand concepts in coding like variables.
I remember browsing Github several months ago and seeing that there was a repo for a Scratch plugin. That really surprised me, I didn't even know it allowed plugins. I'm surprised that there were people willing to make them too! That's awesome!
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.
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!
I am not a parent, by I think there are kids that are interested in computers and programming, and kids that are not. That's the divide between users and makers. That does not mean they can't be creative with something else.
So it's a good thing to try to show them how the magic happens, but being too persistent is pointless.
Try the Minecraft Education Edition coding tools (uses Make:code, which is much like scratch, but a lot higher ceiling). There's other cool make:code options too, or there's straight minecraft command mode...
I tried to teach with scratch to a class of kids, the software worked across tablets like iOS and Android and PCs in incoherent ways, the same code blocks worked slightly or totally differently.
And I'm not gonna give such classes anymore around this software, a waste of time.
“ 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.”
Gorillas.bas anyone?
My programming life started the same way about 30 years ago.
I believe it. Back in college we started out with this visual tool called Raptor and it was a great introduction to programming before diving into more complicated languages like Java. While Raptor was fun, clearly Scratch would have been nicer.
Lego Mindstorms is probably the reason i got into programming.
Moved from using the visual editor as a kid to learning that I could use this weird language called "C"(?) to do even more complex things with a few sketchy libraries.
I think it was a Q-basic game called worm or nibbles or something that I first “programmed” on. Wanted infinite lives or a very short maximum length. Just had to change a variable.
There is no better way for people to show that they understand message passing and the actor model than to have them implement a simple scene in Scratch.
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.
Gifted kids are all really different in their specific strengths. That said, for one with a well-expressed nerd gene, we started at age 6. I would start with an iPad app (slightly simpler container than a browser), maybe that gamifies the whole thing a bit with some easy on-ramps. For us that was Tynker and a bit of Hopscotch. It's pretty easy to tell whether you've got any sparks of interest on your hands, else no point in pushing it.
Scratch is overrated. The color blocks are a fantastic draw for getting a nonprofit funded, but for the children actually using it, the they're just an obstacle. Even at the youngest school ages, children grasp the grammatical concepts of programming effortlessly. It's the math that's the kicker--explaining modulus when they haven't gotten to division yet, binary & hex before they've fully grasped decimal, coordinate systems before they've learned negative numbers, etc...
IMHO, best modern tools for lern2code would be a tie between Lua/Love2d & p5.js.
And for 3rd place... you're going to think this is WAY OUT THERE... C--spare them the gcc esoterica of course--with sample project they can use as a scratchpad. Having types, but without all of the meta complexity of anonymous funcs, OOP, closures, dynamic typing, etc, takes a lot of the complexity (and frustration!) out of learning to program.
At the older & more social ages, the old web APIs were a wonderful stomping-ground. That avenue has since been narrowed-down & greatly so, for obvious reasons.
The Papert/LOGO/PARC stuff should be thrown into the fire. A military-industrial experiment on children; how quickly can we transform the random prole into a technician? Not that any of the researchers were "bad people" or even aware of it. It was a simple necessity of the times & typical "forest for the trees" situation. I think the numerical/visual/spatial primacy of this branch--trying to give kids a visual "feel" for mathematical representations before their brains are ready for the "real deal"--diverts focus away from many of the more "human" uses of the technology.
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.