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.

▲

thatxliner an hour ago | parent | next [-]

If anyone is curious, I've been making this using DeepSeek v4 Flash with Claude Code as the harness

▲

4 hours ago | parent | prev | next [-]

[deleted]

▲

gleenn 4 hours ago | parent | prev | next [-]

That 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 2 hours ago \| parent [-]
		Nope, 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.

▲

dleslie 4 hours ago | parent | prev | next [-]

Opus 4.6 handles elisp just fine. But I suppose YMMV.

▲

2ndorderthought 4 hours ago | parent | prev [-]

Why are we even spending time on this. It's vibe coded slop. The creator probably never even ran it before it got to HN