I built a nanopass-like compiler using Clojure (plus a pattern-matching library[1] that I created) to compile a subset of Python all the way down to bytecode for Untether AI's inference accelerator, a RISC ISA extended with an at-memory compute array. The python subset allowed full control of the array via type-inference instead of intrinsic ops.
I learned how to build a compiler using the nanopass approach and I still think it was a good way to learn, but I would not build another real compiler that way.
Building a lot of passes was great for initial development of the compilation pipeline, but was terrible for maintenance and relatively limited for creating optimizations. Bugfixes in an early pass would frequently require changes across several subsequent ones, especially if any change in representation were required.
About 8 months in, I adopted the a Sea of Nodes[2] approach for the optimizer, type inference, and scheduling but kept my nanopass ingestion, allocation and codegen passes. At the 12 month mark, the v1 compiler was functional but had limitations.
For the next leg of the project I decided to switch fully to Sea of Nodes. The final compiler was much better; orders of magnitude faster, more flexible, much easier to debug and test, more features, and about the same amount of code.
Sea of Nodes takes the core idea of isolating passes to its logical conclusion by narrowing the scope of each change down to a single transformation on a single graph node. Operations are worklist based and can happen in any order, eliminating the pass ordering problem. The IR is a graph that follows simple and consistent semantics from parsing through all phases down to code generation. Going from 20+ IR dialects/sub-dialects to a single graph representation was a huge plus.
I created an inventory program for my wife, who is an artist. There is a lack of tools that can help an artist manage their practice. I actually started it nearly a year ago cycling between all of the free services, switching when I ran out of quota. I got something basic, usable, and extremely poorly designed out of it but it worked for the purpose and was a fun experiment.
Last week I spent two days with Claude Code and was able to clean it up substantially, add a bunch of features and make it really useful. It's nice to be able to encounter a problem, write up a clear description, and have a working feature in less than an hour!
(aside) It's super important for an artist to keep track of their works, prices and where they are and as they get into the hundreds, it's impossible to untangle if you lose track. Also not all galleries are totally upfront and you often need to detect yourself that a piece has been sold and request your money since most sell on consignment.
Initially I built only the most basic features: paintings list with filter/search plus detail/edit, and galleries list with associated paintings and sold/unsold. At that point the app was too complex for the tools of last year to effectively build further.
In the last couple of days I added multi-currency, standardized pricing, exhibit details. Also the most important one, quick selections which are important for proposals, etc, together with a tidy little excel export and web-optimized image export for the selection.
It's been a fun project! I haven't released it yet but am considering it as a side project since I don't think the artist community is likely to buy tools like this in substantial numbers, unfortunately.
I also used CC to put together a static website[1] for my wife which I'm quite happy with. It was decent in one shot and basically done in a few hours!
I have been using FlowStorm heavily for the past several months and it's been a game changer for me.
The software I'm building is very data-intensive, so I can't do full-program tracing. Instead, when I find a problem, I simply add #trace tags to the handful of spots I think may be relevant, re-eval them in the live environment and rerun the failing code. My workflow for solving even tricky-seeming issues has become so fast that fixing bugs doesn't even break me out of the flow I'm in working on whatever it is I'm building. It's really improved my productivity.
The performance impact of tracing has also been surprisingly light. Even when I'm tracing functions that may be called many thousands of times and producing 100,000+ time steps and testing the limits of my 12G heap (I'm generating large amounts of temporary data), the performance overhead of using FlowStorm is only barely perceptible, and in most cases it is not noticeable at all.
Because it's so powerful, I've also started using FS to help me read and understand code. I find it very helpful when I'm reading code to be able to click around and see the data flowing through. Overall this is just an incredibly useful tool!
This [1] IU Compiler Course is excellent. Each week you compile a a successively larger subset of Racket to x86 assembly, gradually expanding the number and sophistication of your compiler passes. It's a great approach, far better than any other compiler courses I've been able to find online.
All necessary materials are available and high quality, including video lectures, book (be sure to get the current version) and software.
Check out this series of videos "The Essence of Linear Algebra"[1] for a really powerful visual and intuitive explanation. It starts with vectors and builds to matrix multiplication and further to several other topics.
I learned how to build a compiler using the nanopass approach and I still think it was a good way to learn, but I would not build another real compiler that way.
Building a lot of passes was great for initial development of the compilation pipeline, but was terrible for maintenance and relatively limited for creating optimizations. Bugfixes in an early pass would frequently require changes across several subsequent ones, especially if any change in representation were required.
About 8 months in, I adopted the a Sea of Nodes[2] approach for the optimizer, type inference, and scheduling but kept my nanopass ingestion, allocation and codegen passes. At the 12 month mark, the v1 compiler was functional but had limitations.
For the next leg of the project I decided to switch fully to Sea of Nodes. The final compiler was much better; orders of magnitude faster, more flexible, much easier to debug and test, more features, and about the same amount of code.
Sea of Nodes takes the core idea of isolating passes to its logical conclusion by narrowing the scope of each change down to a single transformation on a single graph node. Operations are worklist based and can happen in any order, eliminating the pass ordering problem. The IR is a graph that follows simple and consistent semantics from parsing through all phases down to code generation. Going from 20+ IR dialects/sub-dialects to a single graph representation was a huge plus.
[1] https://github.com/pangloss/pattern [2] https://github.com/SeaOfNodes/Simple