Serious (germ of a) question.
Serious (germ of a) question.
A bad idea, probably. LLM output needs to be reviewed very carefully; optimizing the language away from human review would probably make the process more expensive. Also, where would the training data in such a language come from?
In the end, we circle back to lisps, once you're used to it, it's as easy for humans to parse as it is for machines to parse it. Shame LLMs struggle with special characters.
> shame LLMs struggle
That sounds like Stockholm syndrome more than an easy-to-use language.
edit: Lisp -> s-expressions
But don't take my word for it, ask the programmers around you for the ones who've been looking into lisps and ask them how they feel about it.
Also feels like making sure the tokeniser has distinct tokens for left/right parens would be all that is required to make LLMs work with them
But I'm having way more "unbalanced parenthesis" errors than with Algol-like languages. Not sure if it's because of lack of training data, post-training or just needing special tokens in the tokenizer, but there is a notable difference today.
- memory safe, thread safe, concurrency safe, cancellation safe
- locality of reasoning, no spooky action at a distance
- tests as a first class feature of the language
- a quality standard library / reliable dependency ecosystem
- can compile, type check, lint, run tests, in a single command
- can reliably mock everything, either with effects or something else, such that again we maintain locality of reasoning
The old saying that a complex system that works is made up of simple systems that work applies. A language where you can get the small systems working, tested, and then built upon. Because all of these things with towards minimising the context needed to iterate, and reducing the feedback loop of iteration.