4 ms·

I was having this exact thought after I overheard a conversation on a train, where two developers were discussing the quality of TypeScript being generated by C

by Gormo 1mo ago

I was having this exact thought after I overheard a conversation on a train, where two developers were discussing the quality of TypeScript being generated by Claude Code, and how they were getting closer and closer to having all of the architectural requirements, test cases, etc. in place to be able to one-shot correct and functional TypeScript. But if you're going to be relying on the LLM to do all the final-stage implementation work, and you've already got all the guardrails in place to ensure that the final output is performant, secure, correct, etc., then why would you still target TypeScript, which is entirely a kludge to shoehorn type safety into JS for the benefit of human programmers? But then why target JS, if it's just going to sit on top of a complex runtime like Node? Why not just target the language the runtime interpreter itself is written in, and just output clean C? But then C needs to be compiled down to assembly anyway, so why not skip that step and just output assembly? LLMs still have a lot of pitfalls and risk factors, and will always need human oversight, but in this case, what's on the horizon is something that can eventually eliminate all the intermediary bloat that only exists to optimize the development process when human programmers are doing all the grunt work. Eventually, we might be able to do away with the tradeoff between development velocity and runtime performance.

khuey 1mo ago
One obvious reason to have an LLM output a high level language even if you are never going to read the code is because it will require fewer output tokens and therefore be cheaper.
- senderista 1mo ago
  If LLM-generated code continues the human pattern of having roughly the same rate of bugs/LOC regardless of language, then I also expect LLM-generated code in high-level languages to be less buggy.
  - Gormo 1mo ago
    But why would we expect LLMs to continue that pattern over time?
- preg_match 1mo ago
  Typescript is not meaningfully a higher level language than Java, C#, or even Rust. Typescript exists for exactly two reasons: 1. JS is a privileged language and allows you to tap into web and node 2. Type safety is good But TS is not a good language overall. It's just much slower than alternatives and much less safe.
- Gormo 1mo ago
  It's not immediately clear to me why having an LLM output code in JS or Python should inherently consume more tokens than C or assembly. I'd expect token usage to correlate with the complexity of the algorithm being implemented, not with what specific language syntax it's being implemented in. But either way, token consumption is only a relevant concern if you still expect to be using SaaS LLMs by the time you're ready to have them target lower-level code for you.
inerte 1mo ago
It depends on what software you’re building. The npm ecosystem is huge, hosting is easy, etc. Sure C can do it but it will take longer.
- Gormo 1mo ago
  The NPM ecosystem is huge, but it's also full of poorly-coded crap, rife with vulerabilites, subject to supply-chain risks, etc. And much of its convenience comes from the fact that it has a huge set of off-the-shelf libraries for doing things that are properly part of your higher-level business logic, rather than lower-level foundation code, anyway -- those kinds of libraries are popular because they maximize developer velocity, not because they should be third-party dependencies. The kind of stuff that makes sense to include as libraries, e.g. code dealing with foundation-level building blocks, like standard encryption algorithms, audio and video codecs, compression, etc. is exactly where the reference implementations and baseline libraries are all in C in the first place. The point here is that, ultimately, C won't take longer if you're using an LLM. Eventually, you'll get more performant, more secure code targeting the lowest level possible, and mucking around with stuff like NPM is what will both slow you down and produce worse results.
chrisjj 1mo ago
> why would you still target TypeScript, which is entirely a kludge to shoehorn type safety into JS for the benefit of human programmers? To help the hapless humans who have to fix it, silly!
- paulhebert 1mo ago
  Yeah this logic assumes humans never need to read, edit, or understand the code. Maybe we’ll get there but I don’t think we’re there yet. I still regularly run into bugs that agents struggle to solve. And they often churn creating more and more convoluted solutions which are then more error prone and harder to reason about

by Gormo 1mo ago

khuey 1mo ago

One obvious reason to have an LLM output a high level language even if you are never going to read the code is because it will require fewer output tokens and therefore be cheaper.

senderista 1mo ago
If LLM-generated code continues the human pattern of having roughly the same rate of bugs/LOC regardless of language, then I also expect LLM-generated code in high-level languages to be less buggy.
- Gormo 1mo ago
  But why would we expect LLMs to continue that pattern over time?
preg_match 1mo ago
Typescript is not meaningfully a higher level language than Java, C#, or even Rust. Typescript exists for exactly two reasons: 1. JS is a privileged language and allows you to tap into web and node 2. Type safety is good But TS is not a good language overall. It's just much slower than alternatives and much less safe.
Gormo 1mo ago
It's not immediately clear to me why having an LLM output code in JS or Python should inherently consume more tokens than C or assembly. I'd expect token usage to correlate with the complexity of the algorithm being implemented, not with what specific language syntax it's being implemented in. But either way, token consumption is only a relevant concern if you still expect to be using SaaS LLMs by the time you're ready to have them target lower-level code for you.

inerte 1mo ago

It depends on what software you’re building. The npm ecosystem is huge, hosting is easy, etc. Sure C can do it but it will take longer.

Gormo 1mo ago
The NPM ecosystem is huge, but it's also full of poorly-coded crap, rife with vulerabilites, subject to supply-chain risks, etc. And much of its convenience comes from the fact that it has a huge set of off-the-shelf libraries for doing things that are properly part of your higher-level business logic, rather than lower-level foundation code, anyway -- those kinds of libraries are popular because they maximize developer velocity, not because they should be third-party dependencies. The kind of stuff that makes sense to include as libraries, e.g. code dealing with foundation-level building blocks, like standard encryption algorithms, audio and video codecs, compression, etc. is exactly where the reference implementations and baseline libraries are all in C in the first place. The point here is that, ultimately, C won't take longer if you're using an LLM. Eventually, you'll get more performant, more secure code targeting the lowest level possible, and mucking around with stuff like NPM is what will both slow you down and produce worse results.

chrisjj 1mo ago

> why would you still target TypeScript, which is entirely a kludge to shoehorn type safety into JS for the benefit of human programmers? To help the hapless humans who have to fix it, silly!

paulhebert 1mo ago
Yeah this logic assumes humans never need to read, edit, or understand the code. Maybe we’ll get there but I don’t think we’re there yet. I still regularly run into bugs that agents struggle to solve. And they often churn creating more and more convoluted solutions which are then more error prone and harder to reason about