Hacker News Reader

> A compiler will "correctly" process input into unintuitive output, but that's not always what the user intended

Importantly, this behavior is deterministic. If the compiler takes your code and spits out something you did not expect, it will always spit out that same result, given the same input. Once you figure out what went wrong, you've solved that problem.

Generative AI is intentionally not deterministic, and that means you're going to solve the same issues -- hallucinations, primarily -- over and over again.

AI could be deterministic, only it requires sacrificing performance and nobody cares enough. Although algorithms are more predictable, and you can follow an algorithm's steps (even a complex algorithm can be broken into large sequences of steps, which may be broken further).

Determinism is the wrong thing to worry about. As you say an LLM could theoretically be deterministic.

Chaos (prompt instability) is the problem that isn’t solvable if you want to treat an LLM like a compiler by doing something like checking in the prompts and rebuilding the code each time.

In general if you change a single line of source code, a compiler will not produce a completely different program. If you change a single word in a prompt, you will get output that likely doesn’t match a single line of the original output.

Chaos is what leads to unpredictability, and there’s no solution to this on the horizon.

I think you're correct, I'll just point out that compilers are also chaotic today and it is often accepted. A small change to source program can lead to big change in performance. It's especially apparent in high-level and declarative languages - SQL or anything with GC.

With respect to performance that’s true. But I’ve probably spent thousands of hours in my career on performance issues caused by small SQL changes.

And LLM chaos is unimaginably worse. A single white space can result in a program that has zero overlap with the original.

They can guarantee that certain small changes won't create a big change in performance (provably, verified through tests, or trivially). An LLM can't.

“Generative AI is intentionally not deterministic, and that means you're going to solve the same issues -- hallucinations, primarily -- over and over again.”

I see it differently. Sure there are still some hallucinations (but less and less as we progress on), but I see the AI-is-not-deterministic characteristic as a good thing, in the same way that humans and human designers not being deterministic is a good thing. Imagine giving a project/task to a human, and it was completed exactly in the same way with exactly the same outputs as another human that the project was tasked to. Would that be better than each human having varying outcomes of the project? I think most would agree the answer is no.

Determinism isn't the main hurdle. It would be a moderate effort to engineer a deterministic claude that would be no more useful than the current one.

The key characteristic of a compiler is that it takes a source language with a well-defined meaning to a target language with a well-defined meaning.

The reason claude fails to be a compiler is that its input language (english) can't be precisely defined. (And even if that were possible, it would very often fail to preserve the meaning when "compiling")

I agree with what you're putting out there. Every time I see one of these LLM/compiler pieces, the only thing I can think of is that these people don't know what a compiler actually is.

>A compiler almost never produces a wrong output

back log of compiler's bugs can be pretty large

> almost never

But not never. "Almost" is doing a lot of work there.

In a production-grade compiler like LLVM they are rare enough that it compiles giant projects like Linux and Chromium without detectable issues.

Maybe eventually Claude can, since it can write tests, but compilers / (deductive) algorithms have other advantages like efficiency and predictability.

I guess we can come back in 20 years and see if Claude is as reliable as LLVM is today. That would give a comparison between similar aged products.

Not really. As the C language was created around 1972 and by 1973, Unix was rewritten in it. By 1975, Unix was released commercially. That’s like 3 years between design and commercial usage.

Have a go at writing something in 1975's C.

x=-5 Is not x = -5

There's no unsigned int.

It's a better comparison to the usability of Claude than you might think. It's doable, but hardly ideal.

>In a production-grade compiler like LLVM they are rare enough that it compiles giant projects like Linux and Chromium without detectable issues.

https://github.com/llvm/llvm-project/issues

Yea, sure, but there's waay more than Linux or Chromium

we could make a similar observation about determinism. given a set of inputs, the compiler will create the same output each time.

not always true. but very close (pathological coding defects and explicit randomization excluded)

very different than an LLM.

> A compiler is an algorithm and Claude isn't

"Algorithm" is not a word with a definition, so I can't say that you're wrong, but I struggle to see how you conceptualize "algorithm" in a way that does include a compiler but does not include a language model.

I think the distinction you're trying to draw is better captured by comparing inductive and deductive program synthesis.

Those are the exact concepts I was looking for.

A compiler is a deterministic algorithm. Clause is not.

Of course Claude is an algorithm, but it's a very vague, fuzzy and complex one, where you have no way to determine what's going on inside, and no way to know up front what's going to come out.

In computer science, one definition of algorithm is basically any program that runs on a turing machine. By that definition, any LLM is an algorithm.

> "Algorithm" is not a word with a definition

what?

Rogers "Theory of Recursive Functions and Effective Computability", page 1, emphasis is the author's:

§ 1.1 The informal notion of algorithm

In this chapter we give a formal (i.e., mathematically exact) characterization of recursive function. The concept is basic for the remainder of the book. It is one way of making precise the informal mathematical notion of function computable "by algorithm" or "by effective procedure". In this section, as a preliminary to the formal characterization, we discuss certain aspects of the informal notions of algorithm and function computable by algorithm as they occur in mathematics.

I don't understand why you people act like you're stumped by literally, literally page 1 of computer science.

> I don't understand why you people act like you're stumped by literally, literally page 1 of computer science.

… and yet you didn't stop for a moment to consider that in a field as fast-moving as computer science, a concept which might not have had a formal definition in 1967 acquired one in the past 59 years? See, for example, Sipser's Introduction to the Theory of Computation, which has an entire section (3.3 in my 1997 print) titled “The Definiton of Algorithm”.

Yes, did you read that section? It's using different terminology but it's saying exactly what I'm saying (of course it does, it's elementary computer science). There is no accepted definition of the word "algorithm": there wasn't one in 1967, there wasn't one in 1997 and there isn't one in 2026. There are models of computations we can prove to be equivalent to each other, but no commonly accepted definition that captures the way we use the word in normal speech.

This is not page 1 of computer science. And you're being bitchy.

> you're being bitchy

Honestly you're right, I'm sorry. I'm not having a great day and ended up venting online. Logging off.

oh wow. this is a rarity on an internet dominated by toxic rage-bait. apology accepted. I think you probably have interesting things to say on the matter and I look forward to reading them on a better day. respect.

If you pair LLMs/AIs like Claude with a formal verification framework you essentially have a new sort of compiler.

That’s technically correct, but it still means that someone has to write the formal specs that Claude’s output is verified against, and someone has to design the formal languages the specs are written in. And once you have formal specs that truly covers all aspects that you ever will care about, it’s unclear if you couldn’t instead build a non-LLM mechanism that efficiently and deterministically spits out an implementation of such a spec.

I expect in the future it will become hybrid. Formal specs provide guardrails for LLMs / AI but within those guards LLMs will author traditional compiler programs and at times drop-down to manually compile / prove certain snippets.

Could we describe the first humans manually writing Assembly and their own higher level abstractions as "compilers"? Loosely I think we could, and LLMs fit the same mold.

I disagree in the sense that source code (compiler input) leaves little space as to the behavior of the resulting program. With LLMs, either there is much more implied leeway, in which case I’d argue that it’s different in nature. Or the specs will restrict the LLM output to a similar extent as a conventional programming language restricts a compiler’s freedoms, in which case it’s not clear that LLMs are the most expedient technology for generating that output.

Levels of abstraction actually matter with regard to how much observable behavior they leave unspecified, and with regard to how much control is needed over each respective behavioral aspect.