Writing Toy Software Is a Joy | Hacker News Reader

Writing Toy Software Is a Joy

jsbarretto.com

123 pointstodsacerdoti28 comments

I agree 100%.

Here’s why I prefer making “useless” stuff: https://austinhenley.com/blog/makinguselessstuff.html

And my list of similar projects: https://austinhenley.com/blog/challengingprojects.html

I want to do a database and then something involving genetic algorithms next. If I have infinite time, another video game emulator too.

I had implemented some computer games in DOS.

I had wanted to implement a spreadsheet, although I intended a "zoned spreadsheet", which has a zone grid (separate from the data grid), and each zone row has a number of data rows and each zone column has a number of data columns, and some properties are then properties of zone cells and others are properties of data cells. I think this would be better than most existing spreadsheet programs.

I did not know of some of the things that are mentioned there.

Thank you for sharing these! I've been looking for something productive to do over the summer. Why not make some "useless" stuff, huh?

Like most estimates, these seem off by about 3x. At least if you're writing it for the first time.

What I like about these projects is that you can make them as simple or as complicated as you want.

Or more. Actually some of them seem inverted. Simple compiler takes 3 months but a GameBoy emulator takes 2 weeks? That’s not my experience at all.

I was wondering if that was time spent toying with the thing, not necessarily time to a complete or even functional result.

Yes, exactly. The point is to make a toy that proves the concept and gives you insight into the overall design, not to build something with polish!

IMO the difficulties are a bit off, if a 2D physics engine is 5/10, then orbital simulation cannot be 10/10 (even with the difficult stuff like J2 perturbation) ;)

The 10/10 was a copy & paste typo, sorry! Amended now.

Also what's up with this 1 week to make a hash map? In C it's only slightly harder than creating a growable array.

And a POSIX shell is only 3 days. It's an interesting list but the difficulty/time elements are all over the map.

I wrote a shell that's designed to be good enough for the things likely to be passed to system() and popen(). It probably took me a week. To make it a non-toy POSIX shell, I could see potentially taking me a year. The shell is nuts. There's a reason why Thompson got replaced with Bourne and Bourne got replaced with Almquist, and most people use Bash, and then a lot of people started using Zsh. It's simple enough to attract greenfield implementors, and complicated enough for them all to get improved upon.

For some, it depends on the definition of “toy”.

This list reminded me of Build-Your-Own-X (https://github.com/codecrafters-io/build-your-own-x)

That's a great list!

These are all great projects! When I find myself getting burnt out in my job I find that writing a little toy project usually helps be get back some spark. Some projects that weren't listed that I've enjoyed:

- GUI based bot for a small video game

- raft consensus algorithm

- ray casting

- simple b-tree or lsmtree storage engine

I'll also second chip8 emulator as being a good quick fun one! It helps there are ROMs that help quickly validate your implementation also (https://github.com/Timendus/chip8-test-suite)

All great ideas to add to my todo list!

I have never been paid to write code, and my formal CS education is limited to AP Computer Science, and a one-credit Java class in college.

I wrote 20 years ago a backup script implementing Mike Rubel's insight <http://www.mikerubel.org/computers/rsync_snapshots/> about using `rsync` and hard links to create snapshots backups. It's basically my own version of `rsnapshot`. I have deployed it across several of my machines. Every so often I fix a bug or add a feature. Do I need to do it given `rsnapshot`'s existence? No. Is it fun to work on it? Yes.

(I've over the years restored individual files/directories often enough from the resulting backups to have reasonable confidence in the script's effectiveness, but of course one never knows for certain until the day everything gets zapped.)

My personal insight on this: toy projects are fun not because they're small in scope, but because there's no downside to failure.

Production/professional software has significant downsides when they fail (customer unhappiness, professional performance and incentives, etc).

It's also why toy projects open up very innovative pathways. You tend to not be conservative with them, and once in a while something amazing ends up working. Bringing this non-conservativeness to professional software is a skill once developed makes your growth shoot up.

This definitely resonates with me. One of my favorite pasttimes is to code away on a 2D multiplayer RPG engine, and I've ended up doing at least a few of the projects on this list as part of that (ECS framework, voxel renderer, physics engine). Integration with a scripting engine like Lua is another fun one for a list like this, especially if you try to do it in an idiomatic way for your main programming language and/or leverage code generation and metaprogramming.

One thing I've found I enjoy is working on a larger-scope toy project composed of many loosely coupled systems. It works well for me because no matter what type of project I'm interested in working on, I can usually find something applicable within the larger project. Currently on my to-do list are behavior trees and procedural terrain generation, and honestly I don't know how I'm going to decide which to do first.

While the list includes tools which are at the most basic level - how many actually have built their own editor? - I do agree with the author. It teaches you skills, which are great for any software project.

Every time I learn a new language or concept, I try to apply the principle of achieving a basic task with it.

When the meteor framework came out, I created a bullshit bingo in multiplayer mode. People could create their own bingo cards or use predefined bingo cards with business bullshit terms. Anybody worked in a big corp and had a boring meeting? The multiplayer bingo for the win ;) It was never made public, just a proof of work and to get a grasp on how to use the framework, but had a few chuckles

Hell yeah! Ive been off and on working on a version of a 2D physics engine in the form of a zero-player game, been a great joy to hack away at over 2 years.

I, too, had infite time once, and loved spending most of it on coding.

I built a toy OS[0], compiler[1], crypto library[2], a bunch of other stuff, and had a blast.

Now, I have more obligations and more non-coding fun stuff I want to do.

For the programming that I do want to do, I don't particularly enjoy tracking latest breakages from upgrading a random React Native library or drinking from a Kool-Aid firehose of a VC backed open source solution that's going to get acquihired or pivot in 6 months.

I enjoy working with LLMs in turning silly little ideas I have into toy products without grinding through incidental software complexity swamp that is modern software engineering.

[0] https://github.com/senko/Hasenpfeffer

[1] https://github.com/senko/calcc

[2] https://github.com/senko/CyFER

I had done a few related things to some of these, in some of the programs that I had written. I also think that there is a benefit of emulation especially if it is not overly complicated, that the program can run on many computers. I also think that there is the benefit for the computer to be understandable. I may later consider some of the other stuff, such as game that only persists 64-bits.

> Properly handling unicode, syntax highlighting, cursor movement, multi-buffer support, panes/windows, tabs, search/find functionality, LSP support, etc.

You do not need all of these things to make up a text editor. What I would like to have better is a text editor and GUI with better support for non-Unicode text. A feature they didn't mention, that I find useful, is being able to send some text to an external program and replace it with the result; I do sometimes use this feature in vi.

https://3nsi2a2rf4.alternative-accounting.com/game

on mouse stop move over canvas

wont be available for long, that's my idea of toy software, vibe coded the smallest multiplayer game I could think of, about 75% complete. Just taking territories and there's a link to the IP address so you are on the team of the country ip address belongs to. Not smart enough for real game development so have to live within limits of my own abilities.

That's a really neat little gizmo. Makes me want to spend more time playing around with web tech.

Most difficulty and time estimates are random. Chess engine 2 days? Like a really shitty chess engine maybe. Regex engine 4/10, 3 days. Again a really shitty regex engine. What's the point of doing a bunch of projects in a really shitty way?

Reply on news.ycombinator.com