scratch-www VS Node RED

I've always been fascinated by the technology. I spent many hors playing video games and the first dive into the world of development was when I had to code a game on Scratch. The excercise looked pretty easy: Create a Tamagotchi-like game. Let me tell you - It wasn't easy at all for someone of a young age! There were many things that I needed to pay attention to: Things I have never heard of before!

References: Scratch Blockly Google Teachable Machine LEGO Spike Prime

I would be surprised if your first program was C++? Specifically, getting a decent C++ toolchain that can produce a meaningful program is not a small thing?

I'm not sure where I feel about languages made for teaching and whatnot, yet; but I would be remiss if I didn't encourage my kids to use https://scratch.mit.edu/ for their early programming. I remember early computers would boot into a BASIC prompt and I could transcribe some programs to make screensavers and games. LOGO was not uncommon to explore fractals and general path finding ideas.

Even beyond games and screensavers, MS Access (or any similar offering, FoxPro, as an example) was easily more valuable for learning to program interfaces to data than I'm used to seeing from many lower level offerings. Our industries shunning of interface builders has done more to make it difficult to get kids programming than I think we admit.

A good place to start with kids that age is Scratch: https://scratch.mit.edu/

I think going straight to Switch would likely be a tall order. I’d start him off with something where he can be successful right away, writing something he can play on his own computer or share with friends easily.

Scratch[0] is often used to start kids out with programming. He may already use it in school, I know my nephew does, who is around the same age. I made a silly little game in Scratch about a year ago to share with my nephews[1], to try and inspire them a bit. The oldest one quickly went into the code and started tweaking the variables I had set to control things like speed and randomness to make it more chaotic. It’s a good way to learn the concepts of variables, loops, sprites, hit boxes, etc without getting bogged down with the complexity of syntax or a professional game engine. It’s also in the browser, so he can easily share with friends and have them play it, or fork it.

After that, maybe look to something like Godot[2]. It’s free and open source, so he doesn’t have to worry about licensing and all that nonsense that a 12 year old shouldn’t have to think about. I briefly looked and saw some videos of people running the Godot engine on the Switch, but I don’t know what’s involved in that.

I wouldn’t get too tied to a console when learning. Rumors of the Switch 2 are floating around, and who knows, that could mean a whole different path. Starting on the computer avoids this problem, and other huddles. Then if he likes the act of game dev and learning those things, he can cross the bridge to whatever the current console is, if that’s the direction he wants to head.

[0] https://scratch.mit.edu/

[1] https://scratch.mit.edu/projects/733627274/

[2] https://godotengine.org/

For anyone interested in working on visual programming professionally, we use it for creation in Rec Room in a system I built called Circuits https://blog.recroom.com/posts/2021/5/03/the-circuits-handbo...

It has a real place among novice programmers. We even have some experts who use it as a fun alternative to writing text. I don't see visual systems as an effective way to replace everything us experts are doing but they've gotten a ton of mileage in the jr. and learning domain. Scratch (https://scratch.mit.edu/) being another obvious example.

See the email in my profile if you are interested in roles and I'll see if we can find something that fits.

After some days, my sister, who was in class 2 then, came to me and showed me the first program she wrote. It was not a code-based program but a visual program using software called Scratch 3.0. It is similar to NODE-RED but with a different approach, focusing more on programming than wiring together hardware devices. It contains all the node blocks needed to build a simple program without any coding knowledge and is very user-friendly for children new to computer programming.

LiveCode is about the closest literal logical successor to HyperCard.

https://en.wikipedia.org/wiki/LiveCode?wprov=sfti1

That said, I think Scratch is a better learning environment these days and you can develop workable apps in the style of HyperCard. There are plenty of tutorials, documentation, and examples to work from.

https://scratch.mit.edu

For a simple test, I created this Node Red flow that listens to homeassistant/status messages. HA itself will send messages that communicate when its started or when it is about to shutdown. These messages, and a custom message I send from within HA, could be seen:

Also check out https://nodered.org/ and https://github.com/huginn/huginn if you're interested in free and open-source software you can run yourself.

Node-RED (e-RT3) Flow-based, low code development tool

GitHub https://github.com/node-red/node-red GitHub Stars 19.1k Most Recent Update on GitHub 2 weeks ago Open Source License Apache 2.0 Number of Active Contributors This Year 13 Acceptance of External PRs Yes Official Website https://nodered.org/ Documentation https://nodered.org/docs/

Want a low code application for event-driven applications? Then Node-RED is your go to. The new update brings a breaking change, with Node-RED now requiring Node 18.x or later. The team have added new features and updated dependencies to the editor, and there are lots of fixes within the editor. Check out the release notes for all the details.

During a college project in the field of IoT, I came across a simple and powerful solution for wiring together hardware devices called NODE-RED developed originally by IBM. The project was very simple as it only involved controlling electrical appliances and sensing room temperature using a temperature sensor. The whole hardware system was connected to the network using the MQTT Protocol, and using Node-Red, it was just a few minutes of work to connect all sensors and respond accordingly.

Good question.

I expect that we're moving into a phase of AIs talking to AIs, and initially it'll be wasteful (because it'll be mostly English), but eventually, they'll derive their own language and seamlessly upgrade protocols when they determine they're talking to an AI. No clue how that will come about or what that language will look like, but honestly, it's kind of exciting.

Really interesting to think about how they might handle context, as well. Even though we have much bigger context windows (and they'll only get larger), context management is still a resource-management issue, which we'll probably continue to refine, as well. Imagine different strategies for managing both what is brought into the context of each request, as well as what form it could take (level of detail, additional references or commentary on it, etc). Things could get really unreadable even in English, and still be very interpretable for an LLM.

W.r.t. the graph-oriented interfaces, are you thinking something like Node-RED [1]? I'm seeing more and more people mention having LLMs produce non-text or structured outputs, like JSON, UI, and other things. Easy to imagine an LLM that wires together various open-source platforms, on-demand. Something like Node-RED for pipelines/functions, some UI tools for visualization/interactivity, other platforms for messaging, etc...

[1] https://nodered.org/

I skipped to chapter 9 in the article ("Clogged"), and it looked like Pipes failed because it didn't have a large enough team or a well-defined mission. As a result they couldn't offer a super robust product that would lure in enterprise users. "You could not purchase some number of guaranteed-to-work Pipes calls per month" is the quote from the article.

The reason I think that interesting is because that's the model these days for everything from AI tokens to Monday.com seats. It makes me feel like Pipes was before its time.

That said I've been collecting different "business glue" products that are similar to Pipes. To me, like you say, they aren't as interesting, exciting and intuitive as Pipes was, but maybe it just takes a little more digging. I tried to focus on open source tools but some aren't.

- n8n io: https://n8n.io/integrations/mondaycom/

- Node-RED: https://nodered.org/ (just read about this one in this thread)

- trigger dev: trigger.dev

- automatisch.io: https://automatisch.io/docs/

- Activepieces: https://www.activepieces.com/docs/getting-started/introducti...

- Huginn: https://github.com/huginn/huginn

- budibase: https://budibase.com/

- windmill: https://www.windmill.dev/

- tooljet: https://www.tooljet.com/workflows

- Bracket: https://www.usebracket.com/pricing (just SalesForce <-> PostgreSQL)

- Zapier: zapier.com/

Anyway I hope some of these are fun!