I know writing "toy" software has exposed me to new tools I might not have otherwise even known about.

I can't afford much n the way of software, so I've been trying to learn to make do with FOSS.

> Orbital Mechanics Sim

Here's a little toy I made. Try to keep the comet on-screen by clicking to spawn a planet: https://ssl.pepas.com/gravity/gravity.html

Written in C / SDL 1.2: https://ssl.pepas.com/gravity/

As a toy project I can recommend re-creating the core functionality of Git. Its basic functionality beautifully simple.

Checking out Linus’ first commit of Git and comparing it with my own solution was also very interesting (and humbling).

If anyone is interested, here’s my toy Git implementation in Go https://github.com/emanueldonalds/shit

I love that attitude! This is essentially my preferred answer to "what would people do in a post-AGI world when they don't need to work any more".

If I ever have time for it, I would love to program a rotating LED display [0] Looks like magic.

[0] https://www.youtube.com/watch?v=LIvihYPq_mQ

Ever since Nintendo let the mask slip and got up to their old evil bullshit with the Switch 2 launch, I decided to dust off the solution my teenage self came up with: I'll just play the video games I write. Even if they're small and amateurish, they're worlds and experiences crafted personally for me. And I don't have to pay a cent for them, let alone put up with "key carts", DRM bullshit, or we-can-remotely-brick-your-console bullshit.

I'm sure I'll keep buying commercial games from companies with reasonable terms (GOG, maybe?). But writing my own is great fun. It'd be nice if someone else enjoys them, but they're mainly for my own enjoyment.

Oh, and I "vibe code" the old fashioned way: with a REPL and some chill tunes.

My kids (7-10yo) are currently learning programming. I’m debating if I should show them the LLM. Leaning towards no :)

I don't really get a lot of joy out of building copies of things other people have done better than me before. Almost by definition, no list of cool toy projects is going to appeal to me for that reason. I might like the techniques or algorithms employed within them, but frankly if I'm after that kind of knowledge I just find Leetcode and traditional studying to be both higher value and more fun.

But I do like writing programs in some strange new, non-CS domain where very little software to address my very particular needs already exists. Most of the software I've written in the last few years has been of this kind, for the purposes of learning Finnish. It is amazing what a few shell scripts, fzf wrappers, and well-timed calls to an LLM can do for accelerating one's own learning process.

I share the same feeling. Programming can be an entertaining and joyful activity where enthusiasts don't really need to worry about creating something useful that will be shared with others.

It's like cooking a beautiful and tasty gourmet recipe that serves only one.

An anecdote about how a toy project _really_ helped me out:

I work on Dart professionally. I've also been tinkering on a toy programming language that may never see the light of day. My toy language has gone through several incarnations but a while back I was working on adding algebraic datatypes, pattern matching, and exhaustiveness checking to it.

The canonical algorithm for exhaustiveness checking is this paper by Luc Maranget: http://moscova.inria.fr/~maranget/papers/warn/warn.pdf

When I first started dabbling in programming languages over a decade ago, I tried to understand that paper for weeks and just could not wrap my head around it. I don't have much of a formal CS background and that paper was impenetrable to me.

So here I am tinkering on my toy programming language and I run into again. I give it another try and laboriously implement it in my interpreter, basically doing a straight translation. I don't understand the code, but it seems to sort of work. So then I start refactoring it a tiny bit at a time into a style that fits the way I think about code. Eventually the algorithm sort of folds into itself and before I know it, I finally understand how it works. The end result was only a page or so of code, but my toy language had real exhaustiveness checking work.

Meanwhile, at work, I am working on adding pattern matching and exhaustiveness checking to Dart [1]. Exhaustiveness checking here is a much harder proposition because Dart has subtyping, unlike my toy language and the ML languages that Maranget's paper works on.

I'd been hacking away at an exhaustiveness algorithm for Dart based on a couple of papers about Scala's approach but they were sort of approximative and inelegant (in my opinion, maybe they are a great fit for Scala).

But once I understood Maranget's algorithm from implementing it in my toy project, it finally clicked for me how it could be adapted to work with subtyping in a sound, coherent way. I wrote it up as quickly as I could and (with a lot of additional help from a teammate to handle generics), that became the algorithm we shipped:

https://github.com/dart-lang/language/blob/main/accepted/3.0...

It wouldn't have happened if I hadn't coincidentally been working on a toy pattern matching implementation at home.

[1]: https://dart.dev/language/patterns