| |
| ▲ | anon-3988 10 hours ago | parent | next [-] | | > Well, I am on the provocative side that as AI tooling matures current programming languages will slowly become irrelevant. I have the opposite opinion. As LLM become ubiquitous and code generation becomes cheap, the choice of language becomes more important. The problem with LLM for me is that it is now possible to write anything using only assembly. While technically possible, who can possibly read and understand the mountain of code that it is going to generate? I use LLM at work in Python. It can, and will, easily use hacks upon hacks to get around things. Thus I maintain that as code generation is cheap, it is more important to constraint that code generation. All of this assume that you care even a tiny bit about what is happening in your code. If you don't, I suppose you can keep banging the LLM to fix that binary blob for you. | | |
| ▲ | _flux 8 hours ago | parent | next [-] | | > The problem with LLM for me is that it is now possible to write anything using only assembly. While technically possible, who can possibly read and understand the mountain of code that it is going to generate? As a very practical problem the assembly would consume the context window like no other. And another is having some static guardrails; sometimes LLMs make mistakes, and without guard rails it debugging some of them becomes quite a big workload. So to keep things efficient, an LLM would first need to create its own programming language. I think we'll actually see some proposals for a token-effective language that has good abstraction abilities for this exact use. | |
| ▲ | pjmlp 10 hours ago | parent | prev | next [-] | | Lets say years of offshoring projects have helped to reach that opinion. | |
| ▲ | ignoramous 4 hours ago | parent | prev [-] | | > As LLM become ubiquitous and code generation becomes cheap, the choice of language becomes more important. I think, changes to languages/tooling to accomodate Agentic loops will become important. > All of this assume that you care even a tiny bit about what is happening in your code. If you don't... I mean, as software engineers, we most certainly do. I suspect there'll be a new class of "developers" who will have their own way of making software, dealing with bugs, building debugging tools that suit their SDLC etc. LLMs will be to software development what Relativity was to Astrophysics, imo: A fundamental & permanent shift. |
| |
| ▲ | staticassertion 10 hours ago | parent | prev | next [-] | | I don't agree. For one thing, the language directly impacts things like iteration speed, runtime performance, and portability. For another, there's a trade-off between "verbose, eats context" and "implicit, hard to reason about". IMO Rust will strike a very strong balance here for LLMs. | | |
| ▲ | pjmlp 9 hours ago | parent [-] | | Formal specifications and automated testing, will beat any language specific tooling. Hardly much different than dealing with traditional offshoring projects output. | | |
| ▲ | staticassertion 8 hours ago | parent | next [-] | | > Formal specifications and automated testing, will beat any language specific tooling. I don't understand what you mean. Beat any language at what? Correctness? I don't think that's true at all, but I also don't see how that's relevant, it definitely doesn't address the fact that Rust will virtually always produce faster code than the majority of other languages. > Hardly much different than dealing with traditional offshoring projects output. I don't know what you mean here either. | | |
| ▲ | pjmlp 8 hours ago | parent [-] | | Any tool that can plug into MLIR and use LLVM, can potentically produce fast code. Also there is the alternative path to execute code via agents workestration, just like low code tooling work. I see you never had the fortune to review code provided by cheap offshoring teams. | | |
| ▲ | staticassertion 3 hours ago | parent [-] | | > Any tool that can plug into MLIR and use LLVM, can potentically produce fast code. I guess that's sort of technically true, but not even really? Like, obviously you can compile Python to C and then compile that with clang, but it doesn't make it fast. But even if that were the case, there aren't that many languages that have Rust performance so who cares? "Potentially" is sort of saying we might have a future language that's better, but of course anyone would agree. > Also there is the alternative path to execute code via agents workestration, just like low code tooling work. I don't understand how this is relevant. > I see you never had the fortune to review code provided by cheap offshoring teams. I just don't understand why you're bringing it up tbh I don't understand the relevance. | | |
| ▲ | pjmlp 2 hours ago | parent [-] | | It doesn't need to win the benchmarks Olympics, it needs to be fast enough. Plenty of AI based tooling is already trying out this path. Agents execute actions that in the past would be manually programmed applications, now tasks can be automated given a few mcp endpoints. LLMs are already at the same output quality of lousy offshoring companies, thus having to fix a bit of it is something that unfortunately many of us are already used with fellow humans. | | |
| ▲ | staticassertion 2 hours ago | parent [-] | | I feel like maybe we're drifting here. You said this: > Well, I am on the provocative side that as AI tooling matures current programming languages will slowly become irrelevant. And I said I disagree because language directly impacts things like performance. And it does, massively. Like, order of magnitude differences are not hard to achieve simply by changing language. You are now saying that things just need to be "fast enough", but I don't get how that's relevant. The point is that a different language will have different tradeoffs, and AI changes some of the calculus there, but language is still a major component of the produced artifact. If you agree that language has major implications on the produced artifact, then we agree. If you don't, then I'll just once again appeal to the massive performance gaps between different languages. I still am not understanding the offshoaring conversation. |
|
|
|
| |
| ▲ | anon-3988 9 hours ago | parent | prev | next [-] | | If the offshore company provides me a Rust crate that compiles, that is already a lot of guarantee. Now that does not solve the logic issues and you still need testing. But testing in Python is so easy to abuse as LLM. It will create mocks upon mocks of classes and dynamically patch functions to get things going. Its hell to review. | |
| ▲ | throwaway27448 8 hours ago | parent | prev [-] | | What is a programming language used for if not the most formal specification possible? Of course it doesn't matter what language you use if you perfectly describe the behavior of the program. Of course, there's also no point in using LLMs (or outsourcing!) at that point. |
|
| |
| ▲ | ivell 6 hours ago | parent | prev | next [-] | | I would say that current programming languages have a better chance due to the huge amount of code that AI can train on. New languages do not have that leverage. Moreover, current languages have large ecosystems that still matter. I see the opposite. New languages have more difficulty breaking into popularity due to lack of enough existing codename and ecosystems. | |
| ▲ | javier123454321 10 hours ago | parent | prev | next [-] | | Im already using models to reason about and summarize part of the code from programming language to prose. They are good at that. I can see the process being something like english to machine lang, machine lang to english if the human needs to understand. However amother truism is that compilers are a great guardrail against bad generated code. More deterministic guardrails are good for llms. So yeah im not there yet where i trust binaries to the statistical text generators. | |
| ▲ | pbronez 2 hours ago | parent | prev [-] | | Interesting take, what do you think comes next? A programming language optimized for coding agents? |
|
