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.

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?

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.

Thank you.

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.

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?

My suggestion is to try using the contact form again. Sorry that isn't more helpful.

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.

Thanks to you and your team for all you do!

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.

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

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++)

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?

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'd love to be proven wrong around this though.

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.

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.

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.

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.

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 the right way to engage more with more Scratch enthusiasts (kids focused).

You don’t need to buy anything.

https://en.scratch-wiki.info/wiki/Stop_()_(block)

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.

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?

why is that a problem?

Scratch being event-driven is not bad in itself. But there is so much design space to be explored.

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.

Thank you!

At times when I was burned out from programming I found my interest was rekindle d with Scratch.

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.