What is the target age for this series? IMO I thought some parts could be a little slower (like "think of something you do every day..." - pause just a second or two for thought). Not that it matters as the series is 3 years old and I'm no child psychologist
LOGO is a functional programming language for kids and might teach a better mindset. Another more modern option is MS MakeCode Arcade, which is Typescript and Blockly. You can switch back and forth between the two views of your code.
I'm a huge fan of Logo! I wrote a Logo Adventure for Terrapin Logo that they shipped on the C64, the point of which was to show off Logo's list processing and functional features, because most of the other examples were focused on turtle graphics. So I appreciate what you say about teaching the functional and abstract parts of Logo, as well as the procedural and graphical parts like turtle graphics.
Blockly is actually a JavaScript library for rolling your own visual blocks based visual programming languages, from Google. They use it for App Inventor, but that's not all it's used for. It's not one particular language or execution model, but different applications can interpret or compile it into JavaScript or even shaders or WebAssembly.
Here's a wonderful example of a "Falling Sand Game" called "Sandspiel Studio" that uses Blockley for a specialized cellular automata oriented visual programming language, that let you define and play with your own sand/air/water/lava/seed/stem/leaf/flower/whatever particles:
The point that Sandspiel Studio so beautifully illustrates and Blockley so practically addresses is that there are many possible domains, execution models, data models, vocabularies, and user interfaces for visual programming languages: there is no universal VPL that's good for everything, but they're great for many different domains, so you need powerful flexible tools for rolling your own special purpose VPLs.
That's also why Blender supports generic "nodes" you can subclass and customize into all kinds of different domains like shader programing, 2d image composition, 3d content generation, animation, constraints, etc. There are third party and built-in Blender plug-ins that customize nodes into specialized visual languages for generating maps and cities, particle systems, and all kinds of other specialized uses.
So Blockley and Blender Nodes are the visual equivalent of "yacc", for defining custom visual programming languages.
I'm also a huge fan of Snap!, which has all the advantages of Logo (Lisp without parenthesis) and Scratch / eToys / Squeak / App Inventor family of block based visual programming languages, but all the power of Scheme.
If you know Scheme, then it's easy to think about Snap!: it's just Scheme with a visual block syntax, but with some functions renamed to make them easier to learn, plus all the stage and turtle graphics stuff from Scratch, running in a web browser!
I didn't realize until watching in amazement as Jens Mönig used his own creation, that it also has full keyboard support, so you can create and edit programs without using the mouse!
It's much easier to teach Scheme to kids by teaching them Snap!, because the user interface is so much better than a text editor.
I attended Snap!Con2023 in Barcelona recently, and we discussed some interesting possible extensions to Snap:
Grammar defining blocks. Right now you can create your own custom vocabularies of blocks that fit together in particular constrained ways, by writing JavaScript Snap! extensions. Develop a set of blocks for visually defining new grammars and vocabularies of custom parameterizable blocks.
For example, a grammar for representing plants with seeds, roots, stems, leaves, flowers, petals, etc. You can assemble and edit them manually by dragging and dropping from a palette, or write programs that generated and interpret and transform them, and pass them around as data, for example as instructions to the embroidery machine to sew, or logo turtle to draw.
Ken Kahn led a discussion about integrating LLMs like ChatGPT with Snap!. He's the developer of eCraft2Learn for teaching kids AI programming. Ken recently made some cool Snap! extensions for integrating LLMs with the speech synthesis and recognition system, and orchestrating conversations between different characters.
Snap!Con2023: Creative uses of Snap! blocks using large language models like GPT:
But when it comes to LLMs, code generation, and code understanding, JavaScript has two huge insurmountable advantages over Snap! or any other block based visual programming languages:
1) First of all it's extremely well known, by both humans and LLMs.
2) And second of all, there's typically no efficient and faithful way to textually represent block based programs in a way that ChatGPT (or humans) can easily understand and generate.
Of course you could just dump out the XML or JSON save file, but that wastes your token budget, and doesn't work well, because the LLM doesn't inherently understand the syntax and semantics of save files the way it deeply groks JavaScript.
You need to define some equivalent text based language to serialize and deserialize your visual programs, or define some equivalency to an existing language, so you can translate back and forth without loss.
Like Relax/NG has an XML syntax and also a simple concise human readable syntax, both which can express the same things.
But no matter what equivalent language you come up with to serialize your block programs into, it'll never be as well known as JavaScript (unless it IS JavaScript).
I think Snap! could take advantage of its equivalency with Scheme, and you could just parse Scheme into Snap! blocks, and the other way around. And ChatGPT knows scheme pretty well, though it's not as ubiquitous and standard as JavaScript.
Logo would not be as good as Scheme, since it has ambiguities, because you need to know the number of parameters a function uses in order to parse it, since it's essentially Lisp without parens.
Back in 1989 I designed a visual PostScript programming and debugging interface for NeWS, that took the approach of not trying to change or redefine the PostScript language, just to present a visual directly manipulatable interface to what it actually was.
>Abstract: The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS. [...]
>There is a text window onto a NeWS process, a PostScript interpreter with which you can interact (as with an “executive"). PostScript is a stack based language, so the window has a spike sticking up out of it, representing the process's operand stack. Objects on the process's stack are displayed in windows with their tabs pinned on the spike. (See figure 1) You can feed PostScript expressions to the interpreter by typing them with the keyboard, or pointing and clicking at them with the mouse, and the stack display will be dynamically updated to show the results.
>Not only can you examine and manipulate the objects on the stack, but you can also manipulate the stack directly with the mouse. You can drag the objects up and down the spike to change their order on the stack, and drag them on and off the spike to push and pop them; you can take objects off the spike and set them aside to refer to later, or close them into icons so they don’t take up as much screen space.
>NeWS processes running in the same window server can be debugged using the existing NeWS debug commands in harmony with the graphical stack and object display.
>The PSIBER Space Deck can be used as a hands on way to learn about programming in PostScript and NeWS. You can try out examples from cookbooks and manuals, and explore and enrich your understanding of the environment with the help of the interactive data structure display.
I like the way Kodable takes a similar approach of making an easy to use visual user interface to an existing, well defined, universal general purpose language, instead of trying to invent and teach something weird that nobody else uses and students will never see again.
Not to the exclusion of other block languages like Snap! and Blender nodes -- they all have their uses. Snap! is implemented in JavaScript, and lets you call JavaScript functions and integrate libraries with it, like eCraft2Learn.
There's a certain honesty and practical utility about starting simple but working your way towards an actual programming language that kids will encounter in the real world.
Of course I'm disappointed that language isn't PostScript, Lisp, Scheme, Logo, or ScriptX, but JavaScript won the popularity contest, and that's the world we live in.
Despite all its tragic flaws and questionable orientations, I think JavaScript is really a great language to teach kids early on. It's not going away, and it's not purely functional or object oriented, and there's nothing that comes close to it in terms of universality and LLM friendliness.
Hey, thanks for the pointers. Question: are you aware of any materials I can follow to teach kids how to program using Snap!? Snap! has indeed become quite powerful with time, but I struggle to come up with a lesson plan, examples, exercises... whatever will gradually bring kids up to a Scheme-like level of expressiveness and generality.
Definitely! To start with: Brian Harvey's magnum opus, "The Beauty and Joy of Computing", which was used for CS10 at Berkeley, and is "intended for non-CS majors at the high school junior through undergraduate freshman level".
The Beauty and Joy of Computing (BJC) is an introductory computer science curriculum using Snap!, developed at the University of California, Berkeley and Education Development Center, Inc., intended for non-CS majors at the high school junior through undergraduate freshman level. It is a College Board-endorsed AP CS Principles course. It is offered as CS10 at Berkeley.
I’ve evangelized about Snap! frequently on Hacker News over the years, and these links have more details and links to other Snap! extensions and projects (of which there are many amazing ones):
The embedded programming, iot, robotics, embroidery (TurtleStitch), and other tangible computing projects are especially engaging and inspirational for kids.
Much obliged for your help. Logo has the advantage of being immediately applicable to much younger learners (~7) than BJC (~16). There's a big mass of teaching resources (microworlds, etc) that are immediately usable at the beginning, with the possibility of progressing into more complex concepts (e.g., turtle geometry). Maybe, for small children, it'd be a matter of buckling down to port Logo examples to Snap!'s turtle graphics... I may try that.
What a terrific and thorough reply! If you haven't tried it already, have a look at MS MakeCode Arcade. It uses Blockly to render Typescript and you can switch back and forth. It's great for drawing imperative stuff and procedures with blocks, and then looking at the TS to see how they're really implemented.
Here's [0] a small game I wrote in MakeCode which you can play or edit live in the browser.
The current video describing functions is a more basic (pardon the pun) procedural example of Kodable than the object oriented stuff, which it teaches later on.
I've been playing around with Kodable and watching their videos, and what impresses me about it is how much it draws from Alan Kay and Seymour Papert's work, and that it teaches a well known, universal language: JavaScript.
I really loved the Factorio-esque drone automation approach to virtual pets that you can manually lavish attention, feed, groom, and train to do tricks, then program robots (like a hovering roomba) to monitor and satisfy your pet's needs, and even call functions you write with (rhythm game inspired) instructions for making your pets perform tricks!
Kodable reminded me about something Alan Kay said in a discussion about visually programming SimCity, particularly in reference to Warren Robinette's Robot Odyssey, and Thinkin' Things, collection 3, “Let’s Build a Halftime Show!":
From: Alan Kay Date: Thu, 3 May 2018 07:49:16 +0000 (UTC) Subject: Re: Blocky + Micropolis = Blockropolis! ;)
Yes, all of these "blocks" editors sprouted from the original one I designed for Etoys* more than 20 years ago now -- most of the followup was by way of Jens Moenig -- who did SNAP. You can see Etoys demoed on the OLPC in my 2007 TED talk.
I'd advise coming up with a special kid's oriented language for your SimCity/Metropolis system and then render it in "blocks".
Cheers
Alan
------------- * Two precursors for DnD programming were in my grad student's -- Mike Travers -- MIT thesis (not quite the same idea), and in the "Thinking Things" parade programming system (again, just individual symbol blocks rather than expressions).
----
From: Don Hopkins Date: Fri, 4 May 2018 00:43:56 +0200 Subject: Re: Blocky + Micropolis = Blockropolis! ;)
I love fondly remember and love Thinkin’ Things 1, but I never saw the subsequent versions!
That would be a great way to program SimCity builder “agents” like the bulldozer and road layer, as well as agents like PacMan who know how to follow roads and eat traffic!
I am trying to get my head around Snap by playing around with it and watching Jens’s youtube videos, and it’s dawning on me that that it’s full blown undiluted Scheme with continuations and visual macros plus the best ideas of Squeak! The concept of putting a “ring” around blocks to make them a first class function, and being able to define your own custom blocks that take bodies of block code as parameters like real Lisp macros is brilliant! That is what I’ve been dreaming about and wondering how to do for so long! Looks like he nailed it! ;)
Here’s something I found that you wrote about tile programming six years ago.
Etoys, Alice and tile programming ajbn at cin.ufpe.br () 6 years ago
Folks,
I have been trying the new version of Alice <www.alice.org>. It also uses tile programming like Etoys.Just for curiosity, does anyone know the history of Tile Programming? TIA,
Antonio Barros PhD Student Informatics Center Federal University of Pernambuco Brazil
Alan Kay 6 years ago
This particular strand starting with one of the projects I saw in the CDROM "Thinking Things" (I think it was the 3rd in the set). This project was basically about being able to march around a football field and the multiple marchers were controlled by a very simple tile based programming system. Also, a grad student from a number of years ago, Mike Travers, did a really excellent thesis at MIT about enduser programming of autonomous agents -- the system was called AGAR -- and many of these ideas were used in the Vivarium project at Apple 15 years ago. The thesis version of AGAR used DnD tiles to make programs in Mike's very powerful system.
The etoys originated as a design I did to make a nice constructive environment for the internet -- the Disney Family.com site -- in which small projects could make by parents and kids working together. SqC made the etoys ideas work, and Kim Rose and teacher BJ Conn decided to see how they would work in a classroom. I thought the etoys lacked too many features to be really good in a classroom, but I was wrong. The small number of features and the ease of use turned out to be real virtues.
We've been friends with Randy Pausch for a long time and have had a number of outstanding interns from his group at CMU over the years. For example, Jeff Pierce (now a prof at GaTech) did SqueakAlice working with Andreas Raab to tie it to Andreas' Balloon3D. Randy's group got interested in the etoys tile scripting and did a very nice variant (it's rather different from etoys, and maybe better).
Cheers,
Alan
----
He also mentioned how much he loves Warren Robinette (who made Atari 2600 Adventure) and his work for The Learning Company on Rocky’s Boots and Robot Odyssey, which have some wonderful ideas about programming that would be really fun to apply to Kodable!
He called it the greatest game concept he’d ever seen, and he said: "After all these years I still think this is a wonderful concept, and is still waiting for the right designers and builders to marry the concept with the resources needed to make it great to use.”
Warren Robinette’s Work: His visual programming concepts in pioneering games like “Atari 2600 Adventure”, "Rocky’s Boots”, and "Robot Odyssey" could bring powerful, fresh, fun ideas to Kodable.
Robot Odyssey is another game that would benefit from having a clean separation between the graphical/physical modeling simulation and the behavioral parts (both the games levels and the robot programming could be independently separated out) -- this would make a great target for those who would like to try their hand at game play and at robot behavioral programming systems.
This is a long undropped shoe for me. When I was the CS at Atari in 82-84, it was one of our goals to make a number of the very best games into frameworks for end-user (especially children's) creativity. Alas, Atari had quite a down turn towards the end of 83 ... We did get "the Aquarium" idea from Ann Marion to morph into the Vivarium project at Apple ... And some of the results there helped with the later Etoys design.
Cheers,
Alan
----
From: Alan Kay Date: Mon, 12 Nov 2007 20:57:51 -0600 (CST) Subject: Re: Just curious ... To: Samuel Klein, Don Hopkins, Chris Trottier, John Gilmore
Thanks SJ --
We are benefiting here from Don Hopkins' generosity (and of the original designers and owners of these games).
The basic notion is that there are many games that, if modularized with nice separable interfaces, would be great environments for exploring various kinds of "learning by doing". For example, there is a nice separation between the "rules/dynamics" of a games world and the "strategies/actions" of the characters. There could be a third separation to break out the graphics and sound routines as a media environment.
For example, in SimCity, the first and most useful breakout for children would be to allow various UIs to be made that would let children find out about and try experiments with the "city dynamics rules". It's not clear what the best forms for this would be, so it would be great to have a variety of different designers supply modules that would try to bridge the gaps to the child users.
This could work even for pretty young children (we helped the Open Magnet School set up Doreen Nelson's "City Building" curriculum in the third grade of the school and this was very successful -- a child controlled SimCity would have been wonderful to have).
Maybe this separation could be set up via the D-bus so that separate processes written in any language the authors choose could be used. This would open this game up to different experiments by different researchers to explore different kinds of UIs and strategy languages for various ages of children. I think this would be really cool! We would all learn a lot from this and the children would benefit greatly.
A trickier deal would be the world dynamics (I'm just guessing here, but Don would know). This is one of the really great things about SimCity -- it can really accommodate lots of different changes and stitch things together to make a pretty decent simulation without too many seams showing. (Given the machines this game originally ran on, many of the heuristics are likely to be a little patchy. Don has indicated as much.) I think doing a great world dynamics engine for games like SimCity would be really wonderful -- and could even be a thesis project or two.
Don has talked about doing the separations so that many new games can be made in addition to the variations.
Similarly, Robot Odyssey (one of the best games concepts ever) was marred by choosing a way to program the robots where the complexity of programming grew much faster than the functionality that could be given to the robots. This game was way ahead of its time.
Again, the idea would be do make a game in which environment, levels of challenge, and how the robots are programmed would be broken out into separate processes that a variety of gamers and researchers could do experiments in language and UI.
One of the most wonderful possibilities about this venture is that it will bring together very fluent designers from many worlds of computing (more worlds than usually combine to make a game) in the service of the children. We should really try to pull this off!
Refreshingly they did not talk about InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState but tried to explain the reasons for separating code into objects and the difference between a class and an object. Could be useful for kids at a certain level.
Thanks for posting a good comment based on actually looking at their work! Your comment is about https://www.youtube.com/watch?v=X3cFiJnxUBY - I've since changed the URL above.
Do kids really respond to this material? Does it stoke their desire to learn? I feel like these videos take "adult programmer pedagogy" and wrap it in kid-friendly language. Kids don't care about grown-up rationales for programming language features.
Years back, I walked my nephew through a basic programming exercise. I asked him what he would like to see the computer draw. Because he liked trains and Minecraft, he said "a square train". So we booted up Python and used its turtle graphics module to draw a square engine with rectangular smokestacks, a right-angles-only cowcatcher, and square wheels.
Once we had drawn our first wheel, I showed him how to take that code and break it out into a function ("we call this refactoring!"), and how to abstract the x and y coordinates into parameters to the function, so square wheels can be drawn anywhere. Then I showed him how to define a "boxcar" function in terms of the wheel function, so boxcars with square wheels can be added to the train.
I don't know how much of it stuck, but I suspect some of it did because he's 12 now and wants to program space robots.
So we had a goal the kid wanted (a square train), and we worked to the goal, discovering problems along the way, and introducing tools programmers use to solve those problems (like functions and refactoring). OOP can be introduced similarly, with an environment that features multiple turtles, game sprites, or something, and the programmer must instruct a particular object to perform an action.
From what Don Hopkins says about the Kodable software itself, it does support some of these ideas which is cool. So maybe the videos work better as something supplementary to the app.
Yes, it comes with several different kinds of "microworlds" that are games in themselves, but with "levels" you can build, i.e. with tiles or objects, so many different (even user defined) scenarios are possible. Then it has lessons with gradually increasing complexity that you have to solve.
It's really a lot like Robot Odyssey (yet not as hard and limited), but you're learning a real programming language, byte by byte. Starting with drag-and-drops icons and boxes to represent sequences, then conditionals and branching and looping and functions.
The Hardest Video Game You've Never Played | Robot Odyssey
Each of these lessons has corresponding levels that have different simplified visual approaches to programming.
The object oriented stuff comes later, and has some corresponding object oriented simulation game microworlds, like tower defense, virtual pets, and programmable drones, etc.
I wish there was a video showing the virtual pets and Factorio/Robot-Odyssey-esque robot drones you can program to take care of them -- that was really neat, and taught event based programming.
[stub for offtopicness - come on you guys, please don't do this here]
Edit: perhaps I should explain what the "this" is that you shouldn't do here. It's covered by this guideline from https://news.ycombinator.com/newsguidelines.html: "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." (as well as this one of course: "Don't be snarky.")
The trouble with shallow dismissals, such as reflexive reactions to a title, is that they don't contain enough information to be interesting, and they spread like weeds in a thread—especially a new thread, because those are so sensitive to initial conditions. If they spread too much, they choke out good discussion altogether.
I don't favor OO either! The HN archives of yore have a lot of me arguing about it and I like a good OO bitch session as much as anyone. But for a good HN thread, we need comments that are about the specific work being posted, and this is obviously interesting work on teaching programming to kids.
As one of the offenders, I do not see it as that far off topic. If someone posted a video called "Parkour for kids", would you think it off topic if people pointed out that this is just a really, really bad idea?
Getting triggered by a title and regurgitating pre-existing bile about OO (of all things) in the name of protecting children (of all things) was, yes, offtopic and more than a little silly.
I can't agree enough. What other paradigm is so regularly implemented in a way that makes doing it poorly easy(Inheritance), doing it well hard(Composition), and requires a list of caveats so large that it effectively draws down to "only use it in these specific places"?
How does a paradigm like that survive? I might be a fan of functional, but I'm not even saying go that way- stay procedural! Learn your abstractions over time and only build them when necessary.
I think the refrain has more to do with inheritance being heavily promoted as the reason for doing OO in the early 90's till the mid 00's. I believe even Bjarne Stroustrup said if you're not doing inheritance, it's not OO and you should stick to C.
Also, while one can do composition about as easily as inheritance, it still has its warts in languages like C++. If you want to unit test code, it's recommended to use dependency inversion instead of regular composition - there are other good reasons to do DI as well. But when you start coding the same stuff in non-OO paradigms, you realize that it's just much easier - stuff like DI was popularized to get around the flaws of the OO implementation in those languages. The same goes for most OO design patterns.
The number of languages that only support Inheritance and have no version of Composition(or severely compromised versions) is long. What's funny is how many of them make it easier to perform composition as long as you avoid the `class` keyword.
Of these, I would consider only Java to be a true OO language.
Python: Sure, everything is an object, but you don't need to know much about OO to use them. I program in Python professionally, and rarely do I write classes (unless I'm using a framework like Django that requires them). Also, if your language doesn't support data encapsulation, can you even call it OO?
JS: Wasn't OO a later addition to the language? You can get a huge amount done in JS without classes, and that isn't considered poor JS. The general push in JS is to go more functional, not more OO.
C++ is just C with an overly complex OO appended to it. Again, you can write fantastic code in it without relying on OO directly.
JS is a prototypal language, classes are just sugar on top of the prototypes. It's still a flavor of OOP (Self, the original prototypal language, was basically Smalltalk without classes). Ruby makes heavy use of OOP, but allows procedural style of programming similar to Python. You look at Python data science libraries built on top of Numpy such as Pandas, and you see plenty of class stuff.
The web DOM is object oriented. But sure, in these languages you don't have to write your own classes and methods, use inheritance, etc. But plenty of code has used it, and somebody is maintaining, using or extending that code.
The point isn't that OOP is inherently bad and should never be used, but that writing OOP code well (as opposed to merely using objects) is nontrivial. Hence the "seeing how most adult programmers do OO poorly" comment. We've had lots of problems with universities starting off with OOP in the introductory course. I would not deem it suitable for kids unless they are already good at procedural programming.
Of course good stuff has been written in OOP. I personally like that Django uses OOP - it's a good fit. Doing it well is not easy, though. And many problems are easier solved without it.
> JS is a prototypal language, classes are just sugar on top of the prototypes.
Is OOP now a vague term, akin to "functional programming"?
I still maintain that not having data encapsulation (i.e. Python) means it's not OO. (Not that I particularly want it to, either).
