You’ve been there. You’re 200 features deep in a CAD model — sketches, extrudes, fillets, patterns — and then one reference breaks. Everything downstream collapses like dominoes. You spend the next three hours playing detective in a tree of dependencies that looks like a conspiracy board.
We’ve accepted this as normal. It’s not. It’s a design failure baked into the tools themselves.
Traditional CAD software runs on mutable state and imperative operations — the same programming paradigm that gave us null pointer exceptions and buffer overflows. Every time you drag a sketch point, you’re mutating state. Every time a feature fails to regenerate, it’s because some implicit dependency shifted when nobody was watching.
Every CAD bug you’ve ever cursed traces back to the same root cause: mutable state pretending to be design intent.
Now someone has built a programmable CAD environment in Haskell, compiled it to WASM, and dropped it in your browser. It’s called Waterpark, and it suggests something that sounds insane until you think about it for ten seconds: maybe geometry should be logical, not just visual.
Here’s the setup. In Haskell, functions are pure. The same input always produces the same output. No side effects. No hidden state. No surprise mutations. When you define a bracket as a Haskell function, that bracket is a mathematical truth — not a pile of mutable references held together by hope.
You’d think this would be a nightmare for interactive design. CAD needs real-time feedback, right? You drag, you see, you adjust. Functional purity sounds like a straitjacket.
But here’s the twist: that purity is exactly what eliminates the bug class that’s been eating your time for years.
Functional purity isn’t a limitation. It’s a contract that says your design will mean the same thing tomorrow as it does today.
When your CAD model is a pure function, composition becomes trivial. Want to combine two parts? It’s function composition. Want to verify that a design satisfies constraints? It’s a type check. Want to reproduce a model on a different machine, in a different decade? The function evaluates the same way every time — no license server, no proprietary file format, no version-locked binary blob.
Think about what that means for open-source hardware. Right now, sharing a CAD design means hoping the other person has the same software, the same version, the same plugins. It’s fragile. It’s hostile to collaboration. It’s why open-source hardware hasn’t had its GitHub moment.
But if your design is code — real code, in a real language with a real type system — then sharing is a git push. Versioning is a commit log. Reviewing a design is a pull request. Testing a design is a unit test.
The reason open-source hardware never had its GitHub moment isn’t culture. It’s that our tools treat designs as visual artifacts instead of logical ones.
And it runs in the browser. No installation. No license. No 8GB download. You open a URL and you’re programming geometry. That’s not a convenience — that’s democratization. Every kid with a Chromebook can now access a verifiable, composable design tool that treats their ideas as code, not as pixels.
Is it polished? No. Is it going to replace SolidWorks tomorrow? Obviously not. But that’s not the point. The point is that it proves the paradigm works. Functional CAD isn’t theoretical — it compiles, it runs, and it produces geometry you can print.
The CAD industry has spent decades adding features to a broken foundation. More buttons, more menus, more cloud sync — all bolted onto the same mutable-state architecture that makes designs fragile, unverifiable, and proprietary by default.
The future of design isn’t a better GUI. It’s treating geometry as code — composable, testable, and provably correct.
Waterpark is a proof of concept. But it’s pointing at a future where your CAD model is as reliable as your best unit test, as shareable as a git repo, and as open as the web itself. That future is worth building.
FAQ
Q: Isn't functional programming too slow for interactive CAD?
A: No. Haskell compiled to WASM runs in the browser with real-time feedback. The computational overhead of purity is negligible compared to the time you currently lose debugging broken feature trees.
Q: What does this mean for people who aren't programmers?
A: Right now, not much — it's early. But the long-term implication is that CAD becomes more like a spreadsheet: you express intent, the tool guarantees correctness. The learning curve shifts from memorizing menu paths to understanding logic, which is ultimately more empowering.
Q: Is this actually better, or just academically interesting?
A: It's better. The moment your design is a pure function, you get reproducibility, composability, and verifiability for free. No proprietary file format can hold your work hostage. No broken reference can silently corrupt your model. That's not academic — that's a practical advantage you feel every time you open a project.