Live data from Hacker News

LLMs as the new high level language

federicopereiro.com

281–290 of 396 posts

Re: LLMs as the new high level language

#281

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…

> I want to see some assurance we get the same results every time

Genuine question, but why not set the temperature to 0? I do this for non-code related inference when I want the same response to a prompt each time.

Re: LLMs as the new high level language

#282

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

I think it's technically possible to achieve determinism with LLM output. The LLM makers typically make them non-deterministic by default but it's not inherent to them.

Re: LLMs as the new high level language

#283
post #256

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.

Are you certain to predict the JIT generated machine code given the JVM bytecode? Without taking anything else into account that the JIT uses on its decision tree?

For a single execution, to a certain extent, yes.

But that’s not the point I’m trying to make here. JIT compilers are vastly more predictable than LLMs. I can take any two JVMs from any two vendors, and over several versions and years, I’m confident that they will produce the same outputs given the same inputs, to a certain degree, where the input is not only code but GC, libraries, etc.

I cannot do the same with two versions of the same LLM offering from a single vendor, that had been released one year apart.

Re: LLMs as the new high level language

#284
post #197

If we can treat the prompts as the versionable source code artefact, then sure. But as long as we need to fine-tune the output that's not a high level language. In the same way no one would edit the assembly that a compiler produces

If we're able to produce an LLM which takes a seed and produces the same output per input, then we'd be able to do this

There must be good reasons why we don’t have this. I suspect one reason is that the SOTA providers are constantly changing the harness around the core model, so you’d need to version that harness as well.

Re: LLMs as the new high level language

#285
post #260

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?

I once read here on HN that a good metric for filtering controversial comment sections is number of upvotes/comments. If it's bellow one, the thread is probably controversial.

In common parlance, this would be called "ratioing".

Re: LLMs as the new high level language

#286

This is an exaggeration, if you store the prompt that was "compiled" by today's LLMs there is no guarantee that in 4 months from now you will be able to replicate the same result. I can take some C or Fortran code from 10 years ago, build it and get identical results.

That is a wobbly assertion. You certainly would need to run the same compiler, forgo any recent optimisations, architecture updates and the likes if your code has numerical sensitive parts. You certainly can get identical results, but it's equally certainly not going to be that simple a path frequently.

The more important point is that even when you don’t get identical binary output, you still get identical observable behavior as specified by the programming language, unless there’s a compiler bug. That’s not the case for LLMs, they are more like an always randomly buggy compiler. You wouldn’t want to use such a compiler.

Re: LLMs as the new high level language

#287
post #271

>Following this hypothesis, what C did to assembler, what Java did to C, what Javascript/Python/Perl did to Java, now LLM agents are doing to all programming languages. What did Javascript/Python do to Java? They are not interchangeable nor comparable. I don't think Federico's opinion is worth reading further.

Three of Java's top application categories are webapps, banking/financial services, and big data. Node and Pyspark have displaced quite a lot of that.

Re: LLMs as the new high level language

#288
post #273
post #260

Earlier quoted context omitted.

I once read here on HN that a good metric for filtering controversial comment sections is number of upvotes/comments. If it's bellow one, the thread is probably controversial.

Are you saying controversial is good or bad?

Neither, that's up to your individual preference. Although I think that controversial threads have more noise, but sometimes provide a more enjoyable read.

Re: LLMs as the new high level language

#289
If the LLM is a high level language, then why aren't we saving the prompts in git?

Last I checked with every other high level language, you save the source and then rerun the compiler to generate the artifact.

With LLMs you throw away the 'source' and save the artifact.

Re: LLMs as the new high level language

#290
post #122

Earlier quoted context omitted.

There are definitely issues in human software engineering which reach some combination of the following end states: 1. The team is unable to figure it out 2. The team is able to figure it out but a responsible third-party dependency is unable to fix it 3. The team throws in the towel and works around the issue At the end of the day it always comes down to money: how much more money do we throw at trying to diagnose o…

> I don't see why this would ipso facto be different with AI Because humans can learn information they currently do not have, AI cannot?

They can, by putting what they just "learned" into the context window. Claude Code does this without (my) prompting from time to time, adding to its CLAUDE.md things that it has learned about the project or my preferences. Currently this is limited to literally writing it down, but as context windows grow and models continue training on their own usage, it's not clear to me how that will significantly differ from an ability to "learn information they currently do not have".
Post reply on HN