4 ms·

> What might a programming language designed specifically as a UI for coding agents look like? A bad idea, probably. LLM output needs to be reviewed very caref

> What might a programming language designed specifically as a UI for coding agents look like? 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?

embedding-shape 1y ago
So then a programming language designed explicitly for coding languages would need to take human reviews into account, what is the most efficient and concise ways to express programming concepts then? 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.
- hansvm 1y ago
  > once you're used to it > shame LLMs struggle That sounds like Stockholm syndrome more than an easy-to-use language.
  - KerrAvon 1y ago
    I don’t think that would be a real issue in practice. Coding LLMs need to be able to cope with complicated expressions in many languages. If they can produce legitimate code for other languages, they can be taught to cope with s-expressions. edit: Lisp -> s-expressions
  - embedding-shape 1y ago
    Yeah, makes sense it sounds like that. But the crux is probably that most of us learned programming via Algol-like languages, like C or PHP, and only after decades of programming did we start looking into lisps. 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.
- swiftcoder 1y ago
  Surely lisps don't have drastically more special characters as other languages? A few more parens, sure, but less curly braces, commas, semicolons, etc 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
  - embedding-shape 1y ago
    Don't get me wrong, they do work with lisps already, had plenty of success having various LLMs creating and managing Clojure code, so we aren't that far off. 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.

embedding-shape 1y ago

So then a programming language designed explicitly for coding languages would need to take human reviews into account, what is the most efficient and concise ways to express programming concepts then? 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.

hansvm 1y ago
> once you're used to it > shame LLMs struggle That sounds like Stockholm syndrome more than an easy-to-use language.
- KerrAvon 1y ago
  I don’t think that would be a real issue in practice. Coding LLMs need to be able to cope with complicated expressions in many languages. If they can produce legitimate code for other languages, they can be taught to cope with s-expressions. edit: Lisp -> s-expressions
- embedding-shape 1y ago
  Yeah, makes sense it sounds like that. But the crux is probably that most of us learned programming via Algol-like languages, like C or PHP, and only after decades of programming did we start looking into lisps. 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.
swiftcoder 1y ago
Surely lisps don't have drastically more special characters as other languages? A few more parens, sure, but less curly braces, commas, semicolons, etc 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
- embedding-shape 1y ago
  Don't get me wrong, they do work with lisps already, had plenty of success having various LLMs creating and managing Clojure code, so we aren't that far off. 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.