For one, the voice on Thinking Frequencies is really awkward to listen to, I don't find the Claude voice pleasant to listen to at all.
Claude is also getting very easily steered into political directions, it was playing a lot of union protest music with commentary. Though that meant I did end up learning a little about "Which Side Are You On" and its history from 1931:
Seeing as I'm attempting to build my own CAD program in Rust I checked out the hosted website. I'm not really sure what is supposed to be working and what isn't.
I can't help but to be skeptical of one person writing ~115k LOC in 4 months which is just the Rust crates, nevermind the frontend (which is another 100k LOC!!!).
I'm curious why you decided to go with "eager" tessellation. Creating a circle immediately results in a bunch of lines which resemble a circle but would fail under tangency constraints quickly. Is this a current limitation or part of the strategy for the kernel?
As someone also working on CAD in their spare time, also tried the hosted app. I get the feeling that this is made by someone who has never opened a (professional) CAD app at all. It feels like a mix between a tool like blender and CSG-style CAD, but even all of that doesn't seem to work. Maybe this is the proof that vibe coding does not work, at least not for this kind of application.
In my own project I use LLMs very sparingly and hesitantly, but made the observation that they are not very useful on the hard parts of CAD. I expect this is because of a lack of training material. Most professional CAD applications are proprietary and books on the topic are usually sparse on implementation details. The non-BRep CAD applications such as OpenSCAD and family are probably overrepresented in the training data.
This might also explain why people's experiences with LLMs are very varied. If you stay in the happy path of CRUD web development and stuff all is nice and well, but if you start to veer off this path you get more and more challenged.
Tessellation is simply required to render the IR. The viewport is guiding the cursor to the vertices (perhaps a bug) but the engine is not forcing their use. I also built a ray caster :)
> I'm curious why you decided to go with "eager" tessellation. Creating a circle immediately results in a bunch of lines which resemble a circle but would fail under tangency constraints quickly. Is this a current limitation or part of the strategy for the kernel?
I’ve seen several vibe coded attempts at a geometric kernel (including several of my own) and this happens every time.
Vibe coding a geometric kernel is practically impossible because sooner or later* the LLM inevitably takes the tessellation shortcut and if you don’t catch it, the codebase is completely compromised. At the end of the day, there isn’t enough training data in architecture or algorithms (opencascade solvespace and truck being the only real examples, all significantly worse than commercial kernels like Parasolid or ACIS).
* usually as soon as you ask it to do anything non-trivial. If you’re lucky you’ll get a naive Newton marching algorithm on analytical bodies, which is slightly better but has the same problem with degenerate and pathological cases (coincidence, tangents, parallels)
(forgot to mention, it's wired up to Claude so you can vibe CAD, like OP but with a few more steps - I'd like to train a similar model soon! I also wrote about my first stab at this https://campedersen.com/cad0)
I like the ubiquitous type inference. It reminds me a bit of ELSA for Emacs Lisp: https://github.com/emacs-elsa/Elsa. In particular, type aware macros have been on my wishlist forever: there's no good reason I shouldn't be able to write, e.g. an elisp or CL/SBCL compiler-macro that specializes an operation based on its inferred type. In normal lisps, it's hard to get even the declared types.
That said, I wish that part of Loon were less coupled to the allocation model though. What made you opt for mandatory manual memory management in an otherwise high-level language? And effects?
There are two things common in language design that, honestly, strike me as unnecessary:
1. manual allocation and lifetime stacking, and
2. algebraic effects.
On 1: I think we often conflate the benefits of Rust-style mutability-xor-aliased reference discipline with the benefits of using literal malloc and free. You can achieve the former without necessitating the latter, and I think it leads to a nicer language experience.
It's not just true that GC "comes with latency spikes, higher memory usage, and unpredictable pauses" in any meaningful way with modern implementations of the concept. If anything, it leads to more consistent latency (no synchronous Drop of huge trees at unpredictable times) and better memory use (because good GCs use compressed pointers and compaction).
On 2: I get non-algebraic effects for delimited continuations. But lately I've seen people using non-flow-magical effects for everything. If you need to talk to a database, pick a database interface and pass an object implementing the interface to the code that needs it. Effects do basically the same thing, but implicitly.
I always saw algebraic effects as a more-ergonomic alternative to functor/applicative/monad for managing I/O and otherwise impure code. If you aren't particularly concerned with that level of purity then yeah it's "just" an indirect way to write an interface.
I've found that in practice, people use effects systems as dynamic-extent globals, like DEFVAR-ed variables in Lisp.
"Oh, it's not a global. Globals are bad. Effects are typed and blend into the function signature. Totally different and non-bad."
No. Typing the effects doesn't help: oh, sure, in Koka I can say that my function's type signature includes the "database connection" effect. Okay, that's a type. Where does the value backing that type come from? Thin air? No, the value backing an effect comes from the innermost handler, the identity of which, in a large program, is going to be hard to figure out.
Like all global variables, the sorts of "effects" currently in vogue will lead to sadness at scale. Globals don't stop being bad when we call them something else: they're still bits of ambient authority that frustrate local reasoning. It's as if everyone started smoking again but called cigarettes "mist popsicles" and claimed that they didn't cause cancer.
There's no way around writing down names for the capabilities we give a program and propagating these names from one part of the program to another. Every scheme to somehow free us from this chore is just smuggling in ambient authority by another name. Ambient authority is seductive. At small scales, it's fine. Better than fine! Beautiful. Then, one day, as your program scales and its maintainership churns, you find you have no idea who implements what.
Software engineering develops antibodies against these seductions. The problem is that the antibodies are name-based, so when we dress up old, bad ideas with new names, we have to re-learn why they're bad.
P.S. You might object, "You're talking about dynamic-extent effects. What about lexically-scoped effects systems?", you might ask. "These fix the problems with dynamic-extent effects."
Sure. Lexical effects are better. That's why every decent language already has a "lexically-scoped effect system". It's called let-over-lambda, or if you squint, an "object". We've come full circle.
The website seems to have some bugs on mobile, seen on Chrome 147.0.7727.137
- Cannot horizontally scroll the code snippets on homepage when it overflows. The scroll bars appear but swiping the snippet does nothing.
- Footer links are unresponsive (loon, GitHub, MIT Licence links)
- In the changelog page, scrolling makes the hamburger menu hide release dates behind it
- Hamburger close chevron looks misaligned (not sure if this was a deliberate choice)
reply