Live data from Hacker News

LLMs as the new high level language

federicopereiro.com

241–250 of 396 posts

Re: LLMs as the new high level language

#241

Are these kinds of articles a new breed of rage bait? They keep ending up on the front page with thriving comment sections, but in terms of content they're pretty low in nutritional value. So I'm guessing they just rise because they spark a debate?

Vibe coders are the new eternal september

Eternal LLMber

Re: LLMs as the new high level language

#242

After working with the latest models I think these "it's just another tool" or "another layer of abstraction" or "I'm just building at a different level" kind of arguments are wishful thinking. You're not going to be a designer writing blueprints for a series of workers to execute on, you're barely going to be a product manager translating business requirements into a technical specification before AI closes that gap…

> translating business requirements into a technical specification a.k.a. Being a programmer. > The irony is that I haven't seen AI have nearly as large of an impact anywhere else. What lol. Translation? Graphic design?

Writing? Education?

Re: LLMs as the new high level language

#244

Are these kinds of articles a new breed of rage bait? They keep ending up on the front page with thriving comment sections, but in terms of content they're pretty low in nutritional value. So I'm guessing they just rise because they spark a debate?

You can get to the front page easily with dozen upvotes, like from your colleagues and friends. Sadly, that's possibly the only way to get your post some attention here now.

I would disagree. It’s true that scouring the New section reveals a lot of hidden gems, but I know from experience that one in every 20-30 of my submissions ends up on the frontpage.

Re: LLMs as the new high level language

#245
post #230

If we consider the prompts and LLM inputs to be the new source code, I want to see some assurance we get the same results every time. A traditional compiler will produce a program that behaves the same way, given the same source and options. Some even go out of their way to guarantee they produce the same binary output, which is a good thing for security and package management. That is why we don't need to store the…

Anyone doing benchmarks with managed runtimes, or serverless, knows it isn't quite true. Which is exactly one of the AOT only, no GC, crowds use as example why theirs is better.

Reproducible builds exist. AOT/JIT and GC are just not very relevant to this issue, not sure why you brought them up.

Re: LLMs as the new high level language

#246
post #230

Earlier quoted context omitted.

Anyone doing benchmarks with managed runtimes, or serverless, knows it isn't quite true. Which is exactly one of the AOT only, no GC, crowds use as example why theirs is better.

Even those are way more predictable than LLMs, given the same input. But more importantly, LLMs aren’t stateless across executions, which is a huge no-no.

> But more importantly, LLMs aren’t stateless across executions, which is a huge no-no.

They are, actually. A "fresh chat" with an LLM is non-deterministic but also stateless. Of course agentic workflows add memory, possibly RAG etc. but that memory is stored somewhere in plain English; you can just go and look at it. It may not be stateless but the state is fully known.

Re: LLMs as the new high level language

#247
post #234

IDK how everyone else feel about it, but a non-deterministic “compiler” is the last thing I need.

I use them everywhere since the late 1990's, it is called managed runtime.

That is a completely different category. I've never experienced a logic error due to a managed runtime and only once or twice ever due to a C++ compiler.

Re: LLMs as the new high level language

#248

If we consider the prompts and LLM inputs to be the new source code, I want to see some assurance we get the same results every time. A traditional compiler will produce a program that behaves the same way, given the same source and options. Some even go out of their way to guarantee they produce the same binary output, which is a good thing for security and package management. That is why we don't need to store the…

Greedy decoding gives you that guarantee (determinism). But I think you'll find it to be unhelpful. The output will still be wrong the same % of the time (slightly more, in fact) in equally inexplicable ways. What you don't like is the black box unverifiable aspect, which is independent of determinism.

Re: LLMs as the new high level language

#249
I’m not sure I buy this. GPT-5.2 codex still makes design errors that I as an engineer have to watch and correct. The only way I know how to catch it and then steer the model towards a correction is to be able to read the code and write some code into the prompt. So one can’t abstract programming language away through an agent…

Re: LLMs as the new high level language

#250

Earlier quoted context omitted.

Even those are way more predictable than LLMs, given the same input. But more importantly, LLMs aren’t stateless across executions, which is a huge no-no.

> But more importantly, LLMs aren’t stateless across executions, which is a huge no-no. They are, actually. A "fresh chat" with an LLM is non-deterministic but also stateless. Of course agentic workflows add memory, possibly RAG etc. but that memory is stored somewhere in plain English; you can just go and look at it. It may not be stateless but the state is fully known.

Using the managed runtime analogy, what you are saying is that, if I wanted to benchmark LLMs like I would do with runtimes, I would need to take the delta between versions, plus that between whatever memory they may have. I don’t see how that helps with reproducibility.

Perhaps more importantly, how would I quantify such “memory”? In other words, how could I verify that two memory inputs are the same, and how could I formalize the entirety of such inputs with the same outputs?

Post reply on HN