Personal Projects
Here are my most interesting projects, more or less in reverse chronological order.
Tide (2026–)
A programming language, designed to be small and polished, and eventually have a portable implementation. It’s still incomplete, but the design seems promising so far, with a hybrid procedural/functional foundation, Hindley-Damas-Milner type inference, and a carefully designed standard library.
I have a section of my blog written about this project.
Bible Reader (2025–)
A (yet unreleased) Bible reading app. The goal is mostly to have really nice typesetting and a generally pleasant reading experience, to allow you to read the Bible for long periods of time, without interruptions, just like a paper Bible would.
It’s in the middle of a rewrite to Flutter, from web technologies. I’m also working on licencing Portuguese biblical translations from the SBB (the Brazilian Biblical Society).
cmod (2025)
An easy-to-use build system for C. It recursively lists all C source files and links them together, but with incremental compilation and better defaults. There’s an optional config file to link system dependencies or set compiler options.
It was implemented as a shell script that generates a build.ninja and immediately invokes Ninja. It’s missing a lot of features, but it’s enough for all my C programs. Even in its incomplete state, it’s really nice to use.
cmod: a modern C build system that doesn’t require build files
Oken (2022–2025)
Oken was a very ambitious project I redesigned many times and have very little to show for.
The goal was to have a Lisp-style REPL debugger, Tcl-style syntax, a gradual type system, pervasive multimethods, and the ability to compile to C for faster execution. It was supposed to be usable as a system shell, in-process extension language, or for writing full apps.
It was too ambitious and the design never really came together. The closest I ever got was making a prototype interpreter in Lua, following the Mal guide[a], without the Tcl-style syntax, but with all the runtime features I wanted. I realized I had just built a mini Common Lisp with a different syntax.
This project is now frozen until I finish Tide, which has a more well-defined scope.
Lake (2020–2021)
Lake was a “C replacement”. I started with an existing C compiler, and progressively modified it. I changed the syntax, added operator overloading, better macros, structural typing in some cases, generics, and several other QoL improvements. I tried adding ownership tracking (though it was really buggy). But as soon as I tried using it, I realized that blindly copying features from Rust had created an incoherent design.
I gave up when I was trying to implement type inference for generics and was having too many bugs. I realized I no longer believed in the language design, and decided to start from scratch.
After two other from-scratch redesigns (only designs, no code), I gave up. I would need an active “systems programming” project to know what is needed in the design of this language, and I didn’t have one. I might try to create another systems language in the future, but for now I want to work on other design problems.
The Lake programming language: C but sweeter
Craft (2019–2020)
This was a fork of Michael Fogleman’s Craft[a]. I learned a lot about how it worked, and a lot more about how to not write C. It’s not a great codebase. I tried doing some actual game design, but got sidetracked reimplementing everything.
[a] Craft: a simple Minecraft clone written in C using modern OpenGL (shaders)
In the end, the only notable new features were server-side world generation, and real-time raytracing. I wanted to prove that I could do real-time raytracing on my 2014 laptop, and wrote a pixel-shader DDA raymarcher[b] to do it. It had hard shadows and refraction, but any attempt to cast subrays made it too slow. It ran at 30 FPS if the window was half of the screen size, which was enough for me at the time.
[b] Inspired by noeuclid, though I used a different algorithm.
I know today how to do much, much better, from starting with a depth map to doing path tracing with denoising, but I never want to revisit that codebase again. Maybe I’ll rewrite it someday.
Statically-linked Distro (2018–2019)
I unfortunately lost the code for this one. I had made a small “package manager” shell script, with no dependency support. Then, I compiled musl, binutils, GCC, sbase and other packages until my text editor (vis) and window manager (dwm, at the time) were all packaged as statically-linked binaries, compiled on my system.
I got really far. I was using these packages every day, instead of the distro-provided ones. Packaging the X libraries was interesting; because they are not designed for static linking, I had to merge the static libraries with their dependencies (by unpacking and repacking them) so I wouldn’t get errors for missing dependencies.
Eventually, I realized that it’s impossible to statically link OpenGL because it is a driver that needs to match your kernel driver. Which means every graphical program on modern Linux (with Wayland) needs to be dynamically linked, even if only for this reason. So I gave up on the project.
Yax (2018–2019)
Yax was a Unix-like “microkernel”, with multitasking, paging and a virtual file system. The VFS supports Plan 9-style user mounts, and serves as IPC. It’s named after my middle name, Ieks. My last name (Minicz) sounds like another Unix-like microkernel, MINIX.
This was my first big C project. I just followed the OSDev “Bare Bones” tutorial[a] and went from there. My obsession with avoiding bugs, rather than debugging them later, started here, because debugging a kernel is not easy.
I stopped working on it when I started making a disk driver and realized I really don’t like writing drivers. Also, it’s not different enough from Linux to be worth switching to (presumably after a large amount of work to make it usable), so I decided to drop it and consider it done. It has fulfilled its design goals: a “microkernel” with the VFS as IPC.