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.
So if your kid is cool with this kind of clever workaround for the limitations of some piece of crap, you have a future software engineer.
I’ve an anecdote of my own that I still think about semi-regularly:
I was volunteering at a school for a year or so helping them teach 9-11 year olds Scratch. Most of the kids spent the term trying to move sprites across a canvas and making basic platformer style games. It was a heap of fun while also challenging at times.
One day one of the students grabbed my attention and asked for some help making something work. She’d decided to build a trivia game, and was having an issue working out how to make the text for the previous question disappear. When I looked at what she’d built I was blown away. She’d basically built a fully recursive function in Scratch that would iterate through a collection of questions & answers. It was built almost exactly like I’d expect a professional developer to build something. A simple reusable function. I didn’t teach that. She’d never used Scratch before. She’d not done any programming before. It was just the most intuitive way for her to do it.
This, imo, is what makes Scratch a great education platform. It has a couple of very easy to use primitives (such as displaying and moving sprites) and leaves you to build whatever else you need by abstracting things on top of it. This teaches you one of the most foundational programming skills: how to do something complicated with only weird, rudimentary tools.
They don’t have time to hack like that anymore.
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.
Scratch has different constraints than most languages, but I don't view that as a bad thing. Scratch takes what is normally a huge undertaking--sprites--and makes them as much a first-class primitive as stdin/stdout are in most languages. Yeah, this makes the number-guessing and text-adventure games we usually use as teaching projects harder, but it makes it a lot quicker to build visual games. I don't think Scratch needs to change, I think we need to recognize that kids in this generation won't be building the same starter projects that we did growing up.
The sound generator was quite rad too. 3-voice chords. Sines, triangle, etc waveforms.
My 12 year old self liked it a lot.
I 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?
> 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?
Producing text and formatting strings is likely deemed out of scope for that reason. People figuring out clever workarounds is a bonus!
1: https://edutechwiki.unige.ch/en/Microworld
edit: better link
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.
I tried to do a different guessing game, not much more complicated, but it does get hard... I wrote up some thoughts in a thread: https://twitter.com/ianbicking/status/1546207554665172992
It's good that Scratch doesn't change that much, there's lots of books and traded wisdom that retains its value as a result, but there's also some big missing pieces that make some things very hard to write in Scratch, and they could be improved upon but they aren't
Even with that feature, there is no "UI" capability. Getting stuff on the screen still consists of putting up sprites with words over their heads! I ran into this while developing two games on the platform, like this one: Mathtown Alley[0]. It's a crippling limitation even for me, and I write TS professionally.
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 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.
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.
[1] https://web.media.mit.edu/~mres/papers/Clubhouse/Clubhouse.h...
> so it is just a matter of using the tools for what they were created to do.
Ah yes, the vaunted historic MIT culture of 'using things for what they were created to do.'
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.
GitHub only reached 100m repos in 2018[2] - I can't find any more up-to-date numbers, but it's probably around 150m today.
It's crazy to think that Scratch and GitHub operate on similar orders of magnitude.
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.
Modern software, by contrast, is usually too opaque - even free software! The barrier to entry is way too high.
The Internet Archive has these games available to play by the way:
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.
Also applies to adults somewhat - Monad tutorial vs. just use a few monads and see what they do.
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 remember doing the exact same thing in grade school with Gorillas and QBASIC. I actually want to download it now and play it again.
Soon after that wrote program for deleting other programs. actually useful because we didn't know yet how to delete from DOS.
we were kids left with PC with no instructions at all. Parents were busy.
Now in hindsight I see my first steps were somewhat destructive.
As for the other thing, there was some DOS command I learned that forced an immediate reboot. I realized this could be added to the end of an autoexec.bat and create an endless reboot loop.
Well, I thought this was a funny prank so I edited the file on a display PC at Costco. Came back by it later in the trip and it’s still booting and rebooting.
I look back on that and realize it probably had to be replaced and sent to some other state where some tech either had to troubleshoot it or create a new image all together.
Not the best use of value but it was amusing to exert power over computers at such an early age.
In my 8th grade algebra class in a "portable."
Thanks for bringing back the memories though. I looooved playing gorillas!
Great preparation for a career in software haha
However I tried to help my son to write some stuff with it and found it very hard and unintuitive to get stuff done.
There are other, similar systems that are MUCH better for programming, such as Construct3 https://www.construct.net/ and Snap https://snap.berkeley.edu/
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.
Also try https://www.microstudio.dev
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.
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.
Functions ("custom blocks") are just procedures that may-or-may-not mutate global state - This makes it hard to build up abstractions, etc.
Scratch effectively mandates that you write spaghetti code.
I can't recall why I thought it was much better but that was the conclusion I came to when I reviewed them both a few years back.
It was killed by Google (ofc) but still available and works perfectly https://github.com/googlearchive/gamebuilder
The last full build (binary release) is here https://github.com/googlearchive/gamebuilder/tree/master/bui...
Here is the original trailer https://youtu.be/l9Mf_XEZq-A
And some of the tutorial videos are also available https://youtube.com/playlist?list=PLuYHfxlxFzb25nWnevSN5wQVO...
I had a free lesson first thing the next day, so I installed it on the network then had a class of 10 year olds give it a whirl. Had a full scheme of work written by the Monday, and was demoing it to other schools by the summer.
Loved it, loved the scratch board addon hardware, loved the complimentary "makey makey" project, and the cards, and the books and on and on.
incredible project.
Why former?
I used to teach computers/math to 8th graders and while teaching is beautiful school politics, terrible benefits, dealing with patents, among others things made the job of teaching incredibly difficult and draining
Tried the startup thing, my product crashed and burned, work for a charity now.
The primary game I've created during this study: https://scratch.mit.edu/projects/575241838/fullscreen/ Here you can design a level and let a friend pass it - destroy all the bricks.
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:
https://castle.xyz/d/l-_oFKrf5?cxshid=yjIUmDcFo https://s.castle.xyz/qZbz0u2nK10
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.
Also, I think the Elevator Saga is a good idea for learning. And it's just javascript. https://play.elevatorsaga.com/
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 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.
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 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.
It’s like scratch, but it generates a node script to drive a parrot drone: https://github.com/retrohacker/takeoff
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.
* Processing
* Love2D
* Unity / Godot
* Pygame
In the past, Flash filled this niche, I think (although I never programmed in it). Looking at my own list above, and others' responses, I don't think this niche has truly been filled, alas.
Maybe a startup idea?
And yes, I find the exclamation point annoying.
Good question, I personally think p5.js is a great option. JS is very flexible, and the live environment (at editor.p5js.org) is I suppose very similar to scratch. Drawing elements like squares and circles is as simple as square(), circle(), etc. (with parameters). It's very easy to share an publish (could be on github[1], or just link directly from the editor!). Highly recommended for beginners and any quick interactive work really.
It would be great to have a community page like Scratch though.
[1] See a little procedural tree: https://gustavo-nramires.github.io/ :)
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.
She learned scratch and was told it was "coding". This was a massive lie.
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.
You can paste a link to a Scratch URL into the page and it automatically translates it to equivalent JavaScript that can then be edited in the browser or downloaded and edited locally. It's got an impressive and intuitive library behind it and I think it's fantastic.
For making games, Roblox is perhaps a good choice. You can post a modded example game and get your friends playing it very quickly, then iterate rapidly.
It's a text based programming platform centred around creating games and can be used from a young age and into adulthood.
Sadly, they often move on to real computing. They are taught how to use Word and Excel.
I think python is also a great candidate.
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
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.
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.
What could be worse than an introduction to programming that puts a certain number of children off because it's not those things?
Clearly alot of kids manage to drive it enough to their satisfaction, but the failings of Scratch must leave many children behind.
I know my son gave Scratch a go and gave up.
I assume both are true in different cases, and you just have to be careful what part of the community you get involved in.
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.
> 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.
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.
That "Hacking apps with Makey Makey & Scratch" session looks particularly interesting.
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.
1. Writing it is a pain. This is a minor gripe, comparably, but if you already know what you want it is very, very hard to beat just typing out a word. Dragging and dropping through menus makes every little action take too long for comfort. You also miss out on the syntactic sugar that makes coding so much more bearable: little, everyday things, like indexing into an array, or incrementing a value, end up taking just as long as putting in any other function.
2. The information density is atrociously low. Intuitively, it seems like the opposite should be true, after all, in a real programming language you're missing out on pictures and icons and a whole dimension of space. But it turns out that the whole "function reads top-to-bottom" thing packs a lot of flow information.
3. Flow-based value passing robs you of variable naming. In a language like LabVIEW, you very rarely use typed out variable names. Most are replaced by unnamed wires. This subtle feature strips the program of a lot of contextual information, making it hard to read.
4. Linting. If you thought making consistent, presentable code is hard in 1D space, in 2D it's basically intractable. The amount of time I spend futzing with wire pathing is infuriating.
If there is any chance that a project will require software developers some day (if you're starting a business, or inventing something novel, it will) just bite the bullet and use a real programming language. Visual programming just attempts to make the easiest part of programming easier, and makes everything else more painful in the process.
I found graphical programming to be physically debilitating due to eyestrain and wrist fatigue. Granted, this affects each person differently, and I also don't use CAD for the same reason. I can type text with my eyes closed, or while I shift my visual focus away from the screen.
I think a reason why LV programs always seem so unreadable is that the sheer physical effort to clean them up gets the best of the people doing the programming.
A general issue with graphical programming is that you're responsible for the developer interface, and really sweating the details to make it tolerably ergonomic is phenomenally costly in time and effort -- think of how many programmers are employed by Apple or Microsoft.
In contrast, when experimenting with a new or improved text based language, you can piggyback off of existing IDE's or even basic text editors, and get a running head start on adoption by a user community. And the economics are such that languages and IDEs can be supported as open source projects.
There are text based dataflow programming langauges, and I think if LV adopted one of them as an option, folks would stop using the graphical environment after getting over the initial hump of learning to program.
I always show people this:
https://www.ni.com/docs/en-US/bundle/labview/page/gmath/nonl...
Scratch programs also become messy quickly as the complexity increases. Normal code is more compact and easier to actually follow.
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.
One big aspect is handling state. Connecting nodes without side effects is great when each frame is a cycle and all you have to do is transform data into a final result. When actual state is involved it becomes hacky or impossible to do in with only transformations. Other similar hurdles are branching and IO.
The other is having general purpose programming underneath. Shader languages enable a lot, but using a real programming language like C++ somewhere not only opens the door to whatever you need, but allows you to integrate all the libraries already made as well as call out to OS IO APIs etc.
It is amazing though how nice it is to work with an integrated and fluid environment where iterations are updated in real time and errors are narrowed down for you, not to mention profiling broken down by node.
For speed: it's really hard to beat the speed of data entry via keyboard. A well-designed set of keyboard accelerators would cover a lot of ground on making visual programming languages comparable to keyboard programming speed, but I haven't seen anybody pull it off yet.
For scalability, and in the sense I mean scalability of project complexity from a toy desktop project to a distributed system deployment or a low level embedded system: the vast bulk of tools that are available for supporting large projects are built around text and the fact that it's relatively easy to translate a tool working in one text-based language to another text-based language. Git doesn't care what language you're using; it's all text. Diffing tools don't care what language you're using; they diff lines of text. As tools like Copilot grow, they will start by disproportionately giving a power boost to text-based languages because they are built to work with text-based languages.
Anything that's going to work with a visual programming language in a way that is as robust as these tools do needs to treat the language as an abstract syntax tree, not a collection of lines separated by line breaks. And the tools to do that are going to have to be written almost from scratch; it's simply an underdeveloped ecosystem because there's so much fungibility between different text-based languages in terms of allowing tools that work on one to work on another.
There are some systems which try to make it just a straight-forward description --- Drakon Editor comes to mind.
Scalability is an issue --- but screens are larger these days, so may be more workable (I've managed some decently complex models in BlockSCAD:
https://www.blockscad3d.com/community/projects/1385418
A further issue is that if one uses modules/functions, one ends up w/ just a textual description of the algorithm trapped w/in a series of connected/nested blocks.
I prefer to work this way, but I've crashed-burned hard on installation/usage w/ more tools than I can recall off the top of my head (pyFlow, Ryven, GraphSCAD, clikscad, &c.) --- currently I'm just using BlockSCAD and pasting the code into OpenSCAD/RapCAD. I hope that Nodezator (node programming tool done w/ pygame) will work out, but I'm waiting for it to have branches and loops.
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.
For serverless functions/API pipelines, check out (formerly Integromat): https://www.make.com/en
Some even use it for procedural modeling ! (Houdini, Blender)
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.
Yeah, Makecode Arcade has a similar UI with mappings to and from both Python and Javascript.
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.
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. :)
The solution to the problem never got better, it just got prettier. Oh, and the problem just got harder.
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.
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.
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.
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).
I still think Scratch’s interactive environment is impressive.
I think there's a lot of meat on the bones of creating tools that make it structurally impossible to write statically invalid programs. Consider how much time the average developer consumes in a simple iterative process of writing a program, discovering they have made a simple syntax error, and correcting it. IDEs have come a long way in shortening that loop by providing interactive feedback that the current program is invalid, but if the static analysis rules of the language move all the way into the development tooling, you're compiler doesn't even need a static analysis step!
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.
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
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/ ).
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.
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.
Mostly these days I do 3D modeling, so I'm using a Blockly version of OpenSCAD:
https://www.blockscad3d.com/editor/
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:
In the meanwhile, I'm copying OpenSCAD code out of BlockSCAD and pasting it into RapCAD:
https://forum.makerforums.info/t/g-code-preview-using-opensc...
- 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.
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.
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.
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 might be an outlier in that though.
https://scratch.mit.edu/projects/524709085/editor/
1,2,3 and 4 to change ghosts and r to randomise colour.
https://projects.raspberrypi.org/en/paths
Disclosure I work for RPF.
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!
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.
Now I'm in the industry and so are 15% of my classmates from that time.
Every time we open RPi, and I start opening Scratch, he will say, "Daddy, how about we do this" while taking over the mouse and opening a game.
When I'm not looking he'll open Chrome and play YouTube.
To be fair, once we're in Scratch, I don't even know what to do with it.
So it's a good thing to try to show them how the magic happens, but being too persistent is pointless.
And I'm not gonna give such classes anymore around this software, a waste of time.
Gorillas.bas anyone?
My programming life started the same way about 30 years ago.
I love to hear this is still happening.
Kids had more fun than with scratch and learnt programming actual language.
https://blog.codecombat.com/we-have-open-sourced-everything/
Did you run your own environment?
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.
Amazing
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.
Even though it is nice to get kids into programming - it is not what business development will be.
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.
