Full disclosure: Principal Software Engineer here on the Scratch backend...
Scratch is not built to be a "teach your kid programming languages" system, it is based on the work and ideas of the Life Long Kindergarten group at the MIT Media Lab (the director of this group is Professor Mitch Resnick, the LEGO, Papert Professor of Learning Research). The Papert part is where the term Mindstorms comes from (https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...) and was used by the Lego Group when branding those products, and our philosophy is heavily influenced by that.
I can say that the https://scratch.mit.edu/statistics/ are real and we have a substantial footprint of backend services and custom software to support it. We handle on the order of 15-20 million comments/month.
The primary design philosophy is:
Passion: You have a strong interest in a subject/problem to solve/explore
Projects: Build something based on your passions, gain directly interactive experience with it.
Peers: Share your work with folks who are interested and provide feedback to you
Play: It should be fun!
Note that there is nothing in there about STEM/STEAM nor application development. We build and support Scratch to provide creative tools for anyone to explore computation in a from that is relatable and has a low floor for understanding/entry. Having said that, the complexity of what Scratch can do rises sharply the more you work with it and the concepts behind "forking" and opensource are built in via the remix ability on individual projects.
A lot of design thinking goes into the frontend of Scratch to build on a creativity feedback loop that is not focused on learning Python or any other specific language (or the syntax of them, i.e. avoid "why isn't my program working... oh, one too many tabs... or maybe this semi-colon, or maybe this .")
Another part I think is worth raising, the Scratch frontend is a sophisticated virtual machine interpreter that has it's own machine code and model that is executing in a Javascript environment in browser and it is still open source. Google's Blockly project was based on the ideas of Scratch 1.4 and when we ported Scratch 2 away from being Flash based, we partnered with the Blockly group to fork their code base and create Scratch Blocks.
Based on the TIOBE index, we're usually somewhere in the top 20 most popular "programming languages". _eat it Fortran!_
> We build and support Scratch to provide creative tools for anyone to explore computation in a from that is relatable and has a low floor for understanding/entry.
I love this philosophy. Computing is so much more than application development. It's a creative tool, and exploration tool, a tool for finding insight and exploring spaces. Giving people access to those tools without gatekeeping or accidental complexity is fantastic.
The popularity "you need to start with SICP" and "BASIC mutilates programmers" lines of thinking have done so much damage to the way we, as an engineering community, think about the role of computation in society.
Truth is, QBASIC was one of the best programming environments for beginner programmers. Sure it wasn't sophisticated like Turbo Pascal or Smalltalk, but with a single button you could switch back and forth between running your code and live-editing it. If an error occurred you could correct it and continue from where you were. Unfortunately when you got too close to the 640KB memory limit it was no longer possible to fit both the editor and the program in memory at the same time.
> and "BASIC mutilates programmers" lines of thinking have done so much damage to the way we, as an engineering community, think about the role of computation in society.
I learned BASIC when I was about 7 years old by reading the books and banging out code. When I didnt have access to a computer, I wrote the code on paper and entered it later. I can say that it was very hard for me to wrap my head around the C style syntax after a few years of immersion as a kid. I did get over it and I think that the problem helped me develop a deeper understanding of programming concepts. So maybe both can be true?
As a 10 year old reading BYTE magazine what seemed common to C, FORTH, and LISP was that one could add new "words" to the language. It was quite a while before I really got that there was a difference between functions, functions that take functions as arguments (or return values), and functions that take expressions as arguments (or return values.)
Thank you for the amazing work you and the Scratch Team do. I want to second the comment that Scratch works. I'm 16 years old and I discovered Scratch when I was 7. Soon I will be starting my professional career (hopefully something in computer science/engineering/cybersecurity), and it's all thanks to Scratch and the amazing community you have fostered. I don't think I would have ever even considered computers as something interesting to me unless I discovered Scratch.
This is the sort of feedback that makes me cry (in the good way). It was extremely rewarding to have MIT students show up at our group and talking about what effect Scratch had on them and how it helped them make their way to MIT.
Wow. Thanks for posting! I’m curious of your thoughts on other visual programming languages. Specifically LabVIEW.
My first job out of college was at NI where they heavily use LabVIEW. Every engineer in my cohort thought that paradigm was going to take off and over a decade later, it clearly hasn’t. One large factor is cost and proprietary tech, but I’m surprised few outside of the hardware testing world even know such a thing exists.
I now code in Rust and Ruby and don’t yearn for a visual language, but I do wish people who needed to code something up quick could do it without getting knee deep in IDEs, syntax, and terminals.
I’m curious if you’ve got an opinion on that space. What’s holding it back, and if we will ever see a “killer language” for visual programming in the productivity focused space? What do you think would be needed for scratch to fill that role?
I made use of LabVIEW around 2002-2005 and I liked it, working on systems to measure the length of fiber optics down to the femtosecond (it's amazing what you can do with differential wave form/phase analysis), which was then used to write custom C++ code to do these measurements in real-time at a millimeter wave interferometer, enabling the ability to do real-time adjustment to the sample phases for any fiber that was being heated/expanding in the sun.
LabVIEW allowed us to make a very quick demonstration of this as a working concept. Which illustrates what I believe is the most powerful thing about visual programming environments. They can excel at demonstrations and full working solutions without including the parts of computation that are social constructions (language syntax, data structure access and limitations, ...).
I am not convinced that the idea of a "killer language" will happen. While there is a through-line of abstraction heaped upon abstraction, I am unconvinced that these first 60 years of computation in society are going to be visibly recognizable another 60 years from now.
OR!
Linus Torvalds will invent a language that takes over everything, based on how git has consumed almost the entire space of source code management systems (a sociological phenomena/opinionated work flow process) and the success of GNU/Linux more generally.
Version control and diffing (programmatically or mentally) is a major stumbling block. The only graphical language I know of that doesn't suffer from this issue is PLC ladder logic, where the visual representation is forced and it's easy to programmatically show the differences between two versions of a given program, or mentally know exactly what given logic will look like. Pretty much everything else is miserable to compare code in, and this is especially painful when you're initially learning and the examples you're referencing are unhinged LabVIEW spaghetti with no real way to make it any more pleasant to read.
Just some pretext, I am quite experienced in LabView.
One of the major issues with visual languages is not being able to find the right chunk. Yes there is a search feature, but if you don't know the right word to search you are doomed. In my time as a undergrad research assistant I was pumping out complex LabView code and VI's to control whole experiments. But I still would run into problems where I couldnt for the life of me find the block I needed. The most visceral of these was converting something like a double to single or vice versa. I went hunting for the correct block to do the conversion, which would take barely a line of code to do in C++ (the language I knew at the time), and it wasn't in the 'convert' subset of blocks.. I had this vast code that worked, but I couldn't get the last part of the data path completed because this missing stupid block that converts... Took me like an hour to eventually find it after trying everything including Google and NI's documents...
So stuff like that would be the main reason I think they never took off. If you have to hunt and peck trying to find the right box, instead of innately knowing the syntax to do something like converting. Well it just isnt practical, it's easier to lookup in a reference text for the language than to hunt in NI's closed garden crazy house.
That all said and done, LabView had some of the best Connectivity to lab hardware. Over a decade ago you could connect 2-5 devices from 1985-2000 through GPIB, and into your code assuming you had VI's (sometimes you have to make them yourself). It's hard to state how amazing that was, being Able to automate the control and data acquisition of hardware made during the infancy of the internet for research. It also made you quite valuable in your PI's eyes. So unlike most people I know from that era of my STEM career, I was one of the ones that said 'yeah I hate LabView .. . But man is it good at what it does." ... From conversation with grad students these days, it sounds like the libraries in python caught up on that front.
One of the major issues with visual languages is not being able to find the right chunk. Yes there is a search feature, but if you don't know the right word to search you are doomed
how is that different from serching the right function or library in java or python or any other language?
either you know what to search for or there is good documentation or you have to ask somewhere. i don't see how visual languages fare any worse here. except maybe that the visual chunks don't help as much in memorizing their name so you end up searching more often to find it again.
instead of innately knowing the syntax to do something
any syntax of functionality needs to be learned somehow.
It sounds like the discoverability of the LabView “syntax” leaves much to be desired. Perhaps because it’s a proprietary tool used by lots of non programmers, the Google results seem to be really lacking. Much harder to find a top Stack Overflow answer. And the official documentation seems poorly structured.
I get the feeling that graphical programming is the tooling problem.
The fundamental issue is that diff on textual code has no equivalent in a visual paradigm that doesn't have side effects - one example is that color often has meaning in visual systems, and thus is hard to use for showing differences.
I actually spent 3 months and a few $k developing an automotive relay driver, pedal control and dual CAN shield for NI myRIO for firmware development of a small hobby car, electric go-kart, e-bike etc.
The hardware worked, but the usability of the standard blocks .. for some reason it was a disaster compared to other visual design tools like MATLAB Simulink.
Ahh I thought it was Native Instruments - music production is a lot like graphical programming in some sense: you perform a bunch of mathematical operations on sound data by turning knobs, dragging waveforms and drag-and—dropping snippets
I grew up with Applesoft BASIC and later HyperCard - as a kid, I was never a "Developer", but I was always curious - the fact that I could take someone else's source code and change it to my will felt like a superpower.
Now Scratch has more than filled that gap for my own children, and while they may never choose to pursue a career in IT, the fact that they are able to explore the field so easily is invaluable and may help them down the line.
>the fact that I could take someone else's source code and change it to my will felt like a superpower.
The ability to go and tell your computer to do something and then see the computer do it is, in a word, mindblowing. I know it was mindblowing for childhood me.
My experiences with programming were HTML4.01 and CSS2, PHP, Ruby, and some more abstract forms of "programming" (RPG Maker!), and they all gave me a healthy if basic understanding of how computers work and how much power a keyboard and mouse can give to an individual with the proper will and gumption.
Not everyday I come across a fellow RPG Maker around these parts. I hail from the so-called golden age of RPG Maker (RM2K and RM2K3), those were the days I tell you.
I was way too young when I first discovered it, but it was in the 2k/2k3 era too. I could barely wrap my head around how switches and variables worked so my projects never got very far but I remember loving playing the Legion Saga series.
Thank you! I also grew up around the time of HyperCard and BASIC on PCs, and spent hours carefully typing in programs from magazines. I can look back on that and find a lot of warm memories. I can also look at it with a critical eye and question how much I would have learned about general computation principles if there was something like Scratch available during that time period.
>"Scratch is not built to be a "teach your kid programming languages"
You might want to change the wikipedia page that describes you to the whole world
(from the first line of wikipedia)> Scratch is a high-level block-based visual programming language and website aimed primarily at children as an educational tool for programming, with a target audience of ages 8 to 16.
I would say scratch is a brilliant first language for children
I think the message was more that the aim of the project is not to teach kids to be software engineers but rather a platform for creativity and cognitive exploration.
That is not exactly incompatible with the Wikipedia page! It's a programming language and aimed at children but the aim is not to get your kids ready for Go and C++, it's to engage their brain in something positive.
(And of course, neither incompatible with the claim that it _also_ prepares kids to learn Go and C++)
Just want to say thank you! Two of my kids are using scratch regularly (8yo and 6yo). We started using the rpi module and I was surprised how easy it was to start banging out pins to control some motors. The fact that they can use it on a desktop, on a tablet, and it is integrated at school is just fantastic.
I used Lego mindstorms ~15 years ago, and LabVIEW 10+ years ago. Scratch has much clearer concepts and patterns. I always found it difficult to teach students LabVIEW and mostly because of the UI. LabVIEW does have some advantages because of NI, but Scratch is superior IMO.
I'll eventually be transitioning my kids to text languages but there's no replacing the fun they are having with it right now.
Currently we reproduce a lot of apps from Scratch YouTubers. I have been meaning to check out more of the community aspects. Just curious if you have any suggestions on a good way to engage with more Scratch enthusiasts (kids focused).
Go to Scratch site (https://scratch.mit.edu/), create an account and show them how to connect blocks together to make the avatar move? Do it together and then check out other people’s works at the same site. You can build upon them.
Install scratch on a desktop or scratch Jr on a tablet. Watch a YouTube video with them making a simple game and implement it together. My kids liked Zoey from Scratch Team channel. We have made a handful of games together and then they kind of take off from there. I'll show them some new things once in awhile or start off a new program with them, but then I'll just leave them to it and they keep going, making it entertaining for themselves.
While I have the chance here, I want to say thanks to you and your team for the amazing work that you all are doing. I doubt you need further validation, but believe me when I say that the ideas you're describing do work. My entire career in CS started with Scratch in intermediate school (somewhere between 2010 and 2012). Having an interface with a low barrier to entry, particularly for someone whose economic situation didn't allow for engagement with more sophisticated tools, allowed me to begin engaging with computing in ways that I'm not sure I would've been able to otherwise. It was also a bonding experience for my peer group and provided me with a shared interest to meet people over. At the precipice of graduating with a bachelor's in CS, I've been reflecting a lot on how I get here, and Scratch certainly played no small part in that process.
Scratch really seems to be well-designed, from what I've seen.
I actually wanted to use Scratch to program Home Assistant automations. My day job is enough 'serious' programming already. Plus maybe my family would be able to modify some automations.
Me too! I have had various toy projects that make use of the open source Scratch editor to do this exact thing and writing extensions that would enable this. While our our extension system can enable this, we are very careful about adding extensions to the live site that might enable a project to spam connections and inadvertently creating a DDoS system.
Remembering back to when I was a kid, Scratch was absolutely fantastic, and definitely helped me put me on the path I am today. Fantastic work.
With that said (and apologies on using the power of HN here), I've been trying to get in touch with Scratch support to have an old account of mine deleted, but I can't ever seem to get a reply. Would you happen to know who to get in touch with, other than the contact form?
Scratch was what got me into programming around 10 years ago! I was in middle school at the time and now I've just started working full time as a junior engineer. Without Scratch, I probably would've pursued something different. Thanks for your work!
> Scratch is not built to be a "teach your kid programming languages" system, it is based on the work and ideas of the Life Long Kindergarten group
I don't understand why you need to oppose the two, they don't need to be incompatible. It should be possible to keep Scratch the way it is, and simultaneously provide an easier path to other languages for those that which. I'm not saying it's easy. I'm just saying it's a bit sad to discard that option based on philosophical arguments.
I love alternative models of computation and the EV3 mindstorms language was very nice with a type system (including coercion rules) encoded in puzzle shapes, dataflow through "pipes", parallelism through diverging code paths.
With the scratch language I'm not so sure. I feel it's just imperative programming where you can't make a syntax error. You can put strings where numbers go and the semantics is unclear. Parallelism only works through events. Does the IDE provide so much more than Greenfoot and the like do not?
In terms of the EV3 language you could spin up Lego motors in parallel just by drawing two lines from the previous command instead of a single line. Threading in a very literal sense.
Scratch being event-driven is not bad in itself. But there is so much design space to be explored.
I think a lot of the troubles that people have learning things have to do with emotions and motivation. I don't know to what extent people conclude they are completely unmusical because music classes in school don't engage them, for instance, and you learn just to lip sync to avoid a confrontation.
At times when I was burned out from programming I found my interest was rekindle d with Scratch.
First of all, let me tell you that scratch is a wonderful project. I have only one, but pretty important criticism: The tutorials that are packages with the installer use screenshots that are not translated and thus are pretty much worthless unless your kids speak English. I was pretty hyped on scratch, but this pretty much prevents self directed learning from happening.
Given our limited resources, we have translated the tutorials (both the spoken language and the written words in the videos as appropriate) into a subset of the languages that Scratch has been translated into (> 50 languages). The tutorials themselves have been translated into Spanish, French, Japanese, Mandarin, Cantonese, Russian, Turkish, and more. This includes both the spoken words and the written ones. The specific updates to enable this were done in the last two years, so perhaps your experience was prior to that work?
One of my favorite things to show off is switching between Right→Left languages vs Left→Right languages, I encourage everyone to try it! These translations are also a struggle. It adds a lot of extra data to the downloadable and standalone Scratch application and we cannot assume that there will be a network connection available to enable a just-in-time download approach.
Is there any appetite to support more serious programming with Scratch? I’ve created a toy or two but would love to do more. The start/stop flags are the main blocker for me. If there was an option to start automatically and run forever (or until a break) I think I’d do a lot more experimenting with it.
I volunteer for a code club, so maybe I can help you out. I’m not sure what I’m missing in your issue, but Scratch scripts run continuously once the green flag is clicked. You can stop execution programmatically using the stop() block.
My son has language disorder and we just build together a Scratch program to train his inflection skills. Lists of verbs randomly mix with lists of adjectives and nouns.
There are plenty of things that I would instinctively improve about Scratch, especially text outputs, but in the end Scratch is amazing at what it does.
No, thank you! I really mean this, your feedback matters to us as we are continuously working on accessibility issues with both presentation and usability.
scratch seems like a good candidate to be the next flash, in the sense of an authoring tool that makes it easy to create and share little games. do you have any theories as to why scratch games haven't taken off the way flash games did back in the day?
Scratch is not built to be a "teach your kid programming languages" system, it is based on the work and ideas of the Life Long Kindergarten group at the MIT Media Lab (the director of this group is Professor Mitch Resnick, the LEGO, Papert Professor of Learning Research). The Papert part is where the term Mindstorms comes from (https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...) and was used by the Lego Group when branding those products, and our philosophy is heavily influenced by that.
I can say that the https://scratch.mit.edu/statistics/ are real and we have a substantial footprint of backend services and custom software to support it. We handle on the order of 15-20 million comments/month.
The primary design philosophy is:
Passion: You have a strong interest in a subject/problem to solve/explore Projects: Build something based on your passions, gain directly interactive experience with it. Peers: Share your work with folks who are interested and provide feedback to you Play: It should be fun!
Note that there is nothing in there about STEM/STEAM nor application development. We build and support Scratch to provide creative tools for anyone to explore computation in a from that is relatable and has a low floor for understanding/entry. Having said that, the complexity of what Scratch can do rises sharply the more you work with it and the concepts behind "forking" and opensource are built in via the remix ability on individual projects.
A lot of design thinking goes into the frontend of Scratch to build on a creativity feedback loop that is not focused on learning Python or any other specific language (or the syntax of them, i.e. avoid "why isn't my program working... oh, one too many tabs... or maybe this semi-colon, or maybe this .")
Another part I think is worth raising, the Scratch frontend is a sophisticated virtual machine interpreter that has it's own machine code and model that is executing in a Javascript environment in browser and it is still open source. Google's Blockly project was based on the ideas of Scratch 1.4 and when we ported Scratch 2 away from being Flash based, we partnered with the Blockly group to fork their code base and create Scratch Blocks.
Based on the TIOBE index, we're usually somewhere in the top 20 most popular "programming languages". _eat it Fortran!_