Oddly enough, similar story for Python: It's the community.
Scratch is a big deal
141–150 of 306 posts
Re: Scratch is a big deal
#142Scratch has succeeded in the way that counts most - building community. 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 b…
What do you like better about Snap? At a quick glance, it looks almost exactly like Scratch 2.0 (an older version).
The "killer feature" of Snap is the ability to define functions that return a value. In Scratch, you can't do that.
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.
Re: Scratch is a big deal
#143A fun statistic is that Scratch now has over 100 million projects published by users on their website[1]. GitHub only reached 100m repos in 2018[2] - I can't find any more up-to-date numbers, but it's probably around 150m today. It's crazy to think that Scratch and GitHub operate on similar orders of magnitude. [1] https://scratch.mit.edu/statistics/ [2] https://github.blog/2018-11-08-100m-repos/
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. (e…
That's also where many github repos come from. I've seen the instructions to fork the teacher's repo when doing searches.
Re: Scratch is a big deal
#144Is 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.
Re: Scratch is a big deal
#145Interesting 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 meaningf…
> 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.
Re: Scratch is a big deal
#146Earlier quoted context omitted.
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…
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.
Re: Scratch is a big deal
#147Earlier quoted context omitted.
What do you like better about Snap? At a quick glance, it looks almost exactly like Scratch 2.0 (an older version).
The "killer feature" of Snap is the ability to define functions that return a value. In Scratch, you can't do that. 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.
> The "killer feature" of Snap is the ability to define functions that return a value. In Scratch, you can't do that.
Ah, I see now.
Yeah, Scratch really should let you make custom "oval blocks" that return values...
Re: Scratch is a big deal
#148I 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 tha…
> 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?
Just have a sprite 'say' the variable
Re: Scratch is a big deal
#149Name another language where you can be productive on a mobile device.
Scratch is pretty awful on mobile, actually.
Re: Scratch is a big deal
#150Scratch project I reviewed last year which in my opinion was amazing.
https://scratch.mit.edu/projects/524709085/editor/
1,2,3 and 4 to change ghosts and r to randomise colour.