3 ms·
Unfortunately, given the clear LLM basis of this project, s-expressions aren't a great choice. I've found coding agents struggle really hard with s-expression p
by jaggederest 6mo ago
Unfortunately, given the clear LLM basis of this project, s-expressions aren't a great choice. I've found coding agents struggle really hard with s-expression parentheses matching.
Much better to give them something more M-expr styled, I think a grammar that is LL(1) is probably helpful in that regard.
Basically the more you can piggyback on the training data depth for algol-style and pythonic languages the better.
- dleslie 6mo agoOpus 4.6 handles elisp just fine. But I suppose YMMV.
- 2ndorderthought 6mo agoWhy are we even spending time on this. It's vibe coded slop. The creator probably never even ran it before it got to HN
- gleenn 6mo agoThat has definitely not been my experience as of late. I have produced multiple, largeish Clojure projects with AI that have been perfectly formatted and functional. Perhaps you were using an older or possibly smaller model? I am admittedly using Claude with higher end models and mid to high effort but it has been working great for months for me at this point.
- jaggederest 6mo agoNope, but to be fair when you're working on your own novel S-exprs you don't have LSPs to guide the coding agent. I imagine that it works a lot better in the context of a known and understood language environment like Clojure, CL, scheme, etc. The other option would be to write an LSP in a non-S-expr language to ensure that no turn can end with mismatched parens, for example.
- deleted 6mo ago[deleted]
- thatxliner 6mo agoIf anyone is curious, I've been making this using DeepSeek v4 Flash with Claude Code as the harness
- lycopodiopsida 6mo agoIt is absolutely not true, I've vibecoded an app for myself in CL and opus/sonnet had 0 problems with parens and types. Add to it an MCP to work with REPL and it is much more smooth than Go in my experience.