4 ms·

Programming languages are more a UI problem than a mathematical problem. Not sure how it will evolve if coding agents are becoming the “middlemen”.

satiated_grue 1y ago
What might a programming language designed specifically as a UI for coding agents look like? Serious (germ of a) question.
- pona-a 1y ago
  If true ASI ever materializes, JVM bytecode.
  - KerrAvon 1y ago
    This is the correct answer. Why wouldn’t an actual AI just generate raw, fully optimized executables for production?
    - Maxatar 1y ago
      The same reason an actual AI wouldn't play chess by brute forcing every possible position. Intelligent systems are about reasoning, not simply computing, and that requires operating at the level of abstraction where your intelligence is most effective.
    - Timwi 1y ago
      You're contradicting yourself. Raw, fully optimized executables for production would mean machine code for the target platform, not an intermediate bytecode that still requires a VM.
      - hagbard_c 1y ago
        Not really, it would be one of the steps in the chain between design and implementation for a specific hardware platform. That is, unless that code is only ever to run on a single hardware platform, a rare occurrence outside of embedded applications.
- bigfishrunning 1y ago
  > 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
- ojkelly 1y ago
  Until such a point where have agents not trained on human language or programming languages, I think something that’s also really good for people as well. - one obvious way to do things - 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.
JoelMcCracken 1y ago
You can certainly think of them that way if you want. And, you'll be wrong, at least IMO, and in what seems to be the consensus of people who study and work on PLs. "UI" issues, while not at all unimportant, are surface level. Semantics are fundamental. Get the semantics of your language wrong, and you are stuck. Indeed, this is what happens with most popular languages that aren't well-considered: - lang author creates some random new lang, throws whatever feels like a good idea to them into the lang - lang community discover that these features interact in rather surprising ways, ways that keep tripping up newcomers to the language, and would like to change it. - lang author, having had X more years of experience now, identifies that changing the behavior could break user programs who rely on that behavior (wittingly or un-) - lang author decides to write a new, backwards-incompatible version, community has 20 years of turmoil before recovering (python3), if it ever does (perl6).
- sestep 1y ago
  Speaking as an academic PL researcher: you are right that this math-centered view is common in the PL research community, but that doesn't make the opposing view "wrong". There is also plenty of work in the intersection of PL and HCI. Both perspectives are crucial, and neither field is intrinsically superior to the other, despite what some individual researchers feel.
  - andai 1y ago
    Well it's like asking, are the wheels more important on a car, or the engine?
  - ModernMech 1y ago
    If you haven't seen this talk, it touches on exactly this topic: https://medium.com/bits-and-behavior/my-splash-2016-keynote-81cc802f5f6e https://medium.com/bits-and-behavior/my-splash-2016-keynote-... A human view of programming languages - Amy J. Ko In computer science, we usually take a technical view of programming languages, defining them as precise, formal ways of specifying a computer behavior. This view shapes much of the research and development that we do on programming languages, determining the questions we ask about them, the improvements we make to them, and how we teach people to use them. But to many people (even software engineers) programming languages are not purely technical things, but socio-technical things. In this talk, I discuss several alternative views of programming languages, and how these views can reshape how we design, evolve, and use programming languages in research and practice. The upshot is while the "PL as math" and "PL as tool" views have been well researched, if you're a researcher getting started in this area there is plenty of fertile ground out there. We might just have this view that "PL is math" because we've done the most work there, but there are many more applications of programming languages we have not thoroughly explored enough to say they are not just as important.
armchairhacker 1y ago
This is an interesting take, but I disagree. Syntax is a UI problem, but programming languages are more than syntax sugar for assembly. Features like Rust's borrow-checker, type systems, even small things like name resolution and async/await provide "semi-formal"* guarantees. And LLMs are no substitute for even semi-formal guarantees; people have spent lots of money and effort trying to integrate (non-NN, rule-based) algorithms and formal methods into LLMs, some even writing LLM programming languages, because they may be the key to fixing LLMs' accuracy problem. * Not formally defined or verified, but thoroughly defined and implemented via reliable algorithms. A true formal specification is completely unambiguous, and a true formally-proven implementation is completely accurate to its specification. A thorough language specification or reference (like https://tc39.es/ecma262/ https://tc39.es/ecma262/ or https://doc.rust-lang.org/nightly/reference/ https://doc.rust-lang.org/nightly/reference/) is almost unambiguous, and a well-tested compiler or interpreter is almost always accurate, especially compared to LLMs. Cases where true formal guarantees matter exist but are rare. There are many, many cases where LLMs are too inaccurate but well-tested algorithms are good enough.

satiated_grue 1y ago

What might a programming language designed specifically as a UI for coding agents look like? Serious (germ of a) question.

pona-a 1y ago
If true ASI ever materializes, JVM bytecode.
- KerrAvon 1y ago
  This is the correct answer. Why wouldn’t an actual AI just generate raw, fully optimized executables for production?
  - Maxatar 1y ago
    The same reason an actual AI wouldn't play chess by brute forcing every possible position. Intelligent systems are about reasoning, not simply computing, and that requires operating at the level of abstraction where your intelligence is most effective.
  - Timwi 1y ago
    You're contradicting yourself. Raw, fully optimized executables for production would mean machine code for the target platform, not an intermediate bytecode that still requires a VM.
    - hagbard_c 1y ago
      Not really, it would be one of the steps in the chain between design and implementation for a specific hardware platform. That is, unless that code is only ever to run on a single hardware platform, a rare occurrence outside of embedded applications.
bigfishrunning 1y ago
> 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
ojkelly 1y ago
Until such a point where have agents not trained on human language or programming languages, I think something that’s also really good for people as well. - one obvious way to do things - 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.

JoelMcCracken 1y ago

You can certainly think of them that way if you want. And, you'll be wrong, at least IMO, and in what seems to be the consensus of people who study and work on PLs. "UI" issues, while not at all unimportant, are surface level. Semantics are fundamental. Get the semantics of your language wrong, and you are stuck. Indeed, this is what happens with most popular languages that aren't well-considered: - lang author creates some random new lang, throws whatever feels like a good idea to them into the lang - lang community discover that these features interact in rather surprising ways, ways that keep tripping up newcomers to the language, and would like to change it. - lang author, having had X more years of experience now, identifies that changing the behavior could break user programs who rely on that behavior (wittingly or un-) - lang author decides to write a new, backwards-incompatible version, community has 20 years of turmoil before recovering (python3), if it ever does (perl6).

sestep 1y ago
Speaking as an academic PL researcher: you are right that this math-centered view is common in the PL research community, but that doesn't make the opposing view "wrong". There is also plenty of work in the intersection of PL and HCI. Both perspectives are crucial, and neither field is intrinsically superior to the other, despite what some individual researchers feel.
- andai 1y ago
  Well it's like asking, are the wheels more important on a car, or the engine?
- ModernMech 1y ago
  If you haven't seen this talk, it touches on exactly this topic: https://medium.com/bits-and-behavior/my-splash-2016-keynote-81cc802f5f6e https://medium.com/bits-and-behavior/my-splash-2016-keynote-... A human view of programming languages - Amy J. Ko In computer science, we usually take a technical view of programming languages, defining them as precise, formal ways of specifying a computer behavior. This view shapes much of the research and development that we do on programming languages, determining the questions we ask about them, the improvements we make to them, and how we teach people to use them. But to many people (even software engineers) programming languages are not purely technical things, but socio-technical things. In this talk, I discuss several alternative views of programming languages, and how these views can reshape how we design, evolve, and use programming languages in research and practice. The upshot is while the "PL as math" and "PL as tool" views have been well researched, if you're a researcher getting started in this area there is plenty of fertile ground out there. We might just have this view that "PL is math" because we've done the most work there, but there are many more applications of programming languages we have not thoroughly explored enough to say they are not just as important.

armchairhacker 1y ago

This is an interesting take, but I disagree. Syntax is a UI problem, but programming languages are more than syntax sugar for assembly. Features like Rust's borrow-checker, type systems, even small things like name resolution and async/await provide "semi-formal"* guarantees. And LLMs are no substitute for even semi-formal guarantees; people have spent lots of money and effort trying to integrate (non-NN, rule-based) algorithms and formal methods into LLMs, some even writing LLM programming languages, because they may be the key to fixing LLMs' accuracy problem. * Not formally defined or verified, but thoroughly defined and implemented via reliable algorithms. A true formal specification is completely unambiguous, and a true formally-proven implementation is completely accurate to its specification. A thorough language specification or reference (like https://tc39.es/ecma262/ https://tc39.es/ecma262/ or https://doc.rust-lang.org/nightly/reference/ https://doc.rust-lang.org/nightly/reference/) is almost unambiguous, and a well-tested compiler or interpreter is almost always accurate, especially compared to LLMs. Cases where true formal guarantees matter exist but are rare. There are many, many cases where LLMs are too inaccurate but well-tested algorithms are good enough.