DEV Community

Cover image for Why Scratch is the Ideal Development Environment
Josh Pullen
Josh Pullen

Posted on

Why Scratch is the Ideal Development Environment

I don't need to tell you that Scratch is not a professional tool. Certainly, there are some very impressive people creating very impressive projects, but they are the exception, not the rule.

Scratch is designed for children. It isn't built to be powerful. It isn't designed to be fast. You can't pass around arrays or objects as data, and you can't create a function that returns a value. As a tool for real development, Scratch is worthless. But Scratch gets one thing right: It makes programming intuitive.

You Know Your Options

In Scratch, every "block" — every feature and method available to you — is visible on-screen in a single scrolling panel:

You don't need documentation because everything you can possibly do is right there in front of you. And if you don't know what something does, you can just try it.

Experimentation is Everything

Want to run some code? Just click it. It's that simple. If you have a block or two, you can click them and they will run. Always.

This means that you don't need documentation, tutorials, or anything except a willingness to try. If you find a block that looks like what you want to do, you can click it — even while your project is running — and see the result immediately.

Military-Grade Hot Reloading

In Scratch, your project is a stage and you are the director. Code is merely a way of communicating with your actors (technically, "sprites"). You can, of course, give your actors a script ahead of time, but there's nothing stopping you from giving additional directions as the scene unfolds.

The Scratch interpreter is baked directly into the editor, which means that when you interact with your code you are manipulating the world directly. You can change a script while it's running, and it will just work. That's magic.

The Result? Insight and Intuition.

When you combine these elements together, what you get is a very intuitive programming experience. It's underpowered, of course, but it's also empowering. By giving you as many tools as possible to see into your project and manipulate it, Scratch makes it easy to get a grasp on how code works. When you want to make something, you just start clicking bricks. You can see how they fit together in a way that feels tangible. Code is no longer a black box.

I Want Scratch Back

I spent a lot of time with Scratch in my early years, but eventually moved on to bigger and better(?) things. There's a lot to love about the broader programming landscape, but I'm honestly not thrilled to have left behind the editing experience that was once so near and dear to my heart.

But why are intuitive programming environments reserved for children? Surely even the big kids could use a little extra assistance. The challenge of programming is understanding what's happening inside our little black boxes. But the more that we can poke holes in the box — the more that we can give insights into how our code looks and feels from the inside — the better software we will be able to create.

Top comments (2)

Collapse
 
bubbabrix profile image
Bobby/Bubba

Great article, Josh. I couldn't have put it better myself. I'm glad to see your honesty in that you're not afraid to list the flaws that Scratch has, but you want people to realize that there is some significant meaning in the program, even to this day. Even if you're not around on the site anymore, I'm glad you're still around to support the site in spirit and elsewhere on the web. I'm practically done with creating content on Scratch myself, but I did promise my followers one final project.

Collapse
 
pulljosh profile image
Josh Pullen

I have a few extra thoughts that were axed from the main article in the name of keeping it concise, but I want to extrapolate a bit more here for those who are interested.

I actually think that the idea in this article — that we should build languages and tools that make code more intuitive — is starting to take hold.

In the world of frontend development, I've spent a lot of time with React and have found the component-based architecture to be very useful when trying to "mold" a program rather than write it top-to-bottom. I am also hopeful that Dan's work on hot reloading will bring us closer to the promised land of truly live code editing.

Perhaps more interesting to me is SwiftUI and the Xcode editor that goes with it. I have never so much as dabbled in the Apple ecosystem (except my childhood iPod touch), but some of what I'm seeing is incredible. Check out this clip of app creation with SwiftUI:

We've hit two out of three marks here: We can see all the code options available (in this case, in a few different menus), and the live reloading is top-notch. The experimentation aspect isn't quite analogous to Scratch, but the entire experience still comes pretty darn close.

It's not really surprising that Apple, of all companies, has nailed the integrated, end-to-end ecosystem experience with a language, an editor, and target devices all built as a cohesive whole. Obviously, there are downsides to walled gardens, but I think that we can learn a lot from SwiftUI and the development experience it provides.