sroerick

I just don't do this at commit time. I might make 100 commits and then dig through code and find some bad architecture stuff.

I never have operated this way. Code reviews were a basic sanity check, a chance to implement best practices, and a chance to teach these things to juniors.

If I was concerned about something breaking, I'd duscuss test coverage.

Was I doing it wrong this whole time??

The dynamic features you get with a full blown REPL are, in some specific cases, worth the trade off you get by losing the guardrails (which I call Rubber Baby Buggy Bumpers).

You're right though - strong typing feels like a cheat code.

Folks have found it useful to just point gippity at the page and ask questions

Webpages, zettelkasten, todo, workout, diet tracker. It's a web framework! Creating an endpoint is just like making a function in emacs.

Since lisp is homoiconic the AST is just raw JSON. I save the AST in JSON stores in Postgres. But you can clone the AST down and then eval against a local copy of the REPl. So you get local eval for free.

Of course you have to rebuild git to manage a branching REPL in this way.

While I am extremely taken with Lisps and the lisp way of doing DSLs, I would probably go with an OCaml to make a DSL for a company specific ERP. It seems a better way to go about the problem.

Lisp, on the other hand, I have found to be extremely good at domains which seem the same but which are tremendously different. For example, a workout app is a surprisingly complex domain. Different exercises have different storage models and functions, as do different training sessions and different programs. Rather than try to build a monoprogram, one training app to rule them all, I find lisp wonderful for making "microprograms".

This bears resemblance to Accounts Payable and Accounts Receivable but I don't think Lisp would be a good fit for those. Perhaps a Lean or a Rocq, something with proofs.

> We already know that if the AIs want a better language suited to AI efficiency, they’ll come up with their own.

My agents seem to really like Tree Calculus and have bullied me into working on a language which uses it.

I think Lisp and an ML are kind of the dynamic (static) duo. I still think MLs are the best for complex projects, but interpreted languages are pretty neat too. Python, Rust, and Golang are all great, also.

I think a tree calculus language might be the actual best - but it's too soon to say

Really, languages are great for LLMs.