A compiler is an algorithm and Claude isn't*. A compiler almost never produces a wrong output, even when compiling an extremely complicated program. But a compiler must be clearly defined and is limited to input/commands it's defined for. A compiler will "correctly" process input into unintuitive output, but that's not always what the user intended (e.g. omitting large sections of code that are undefined behavior). Claude makes mistakes, but can process any input/command expressible in training data, and has more potential to infer when something is unintentional.

Tools like Claude are great at building algorithms, then tests to verify them. The algorithms they build aren't just compilers, but any software that can be verified. Even though Claude may not be a compiler, it has the potential to (at least if it improves) create production-grade software that can be verified, like other compilers. But maybe not good UX without human input (expanded to any subjective experience, like video games).

* Not a "source language to target language" deductive algorithm. Technically Claude is an algorithm to predict the next token, but acting as a compiler or anything else it's an inductive heuristic, because it guesses (https://stackoverflow.com/q/2334225)

▲

thomascgalvin 6 hours ago | parent | next [-]

> 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.

▲

cobbal 5 hours ago | parent | next [-]

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")

▲

armchairhacker 6 hours ago | parent | prev | next [-]

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).

▲

sarchertech 5 hours ago | parent [-]

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.

▲

js8 5 hours ago | parent [-]

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.

	▲	sarchertech 5 hours ago \| parent \| next [-]
		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.
	▲	armchairhacker 5 hours ago \| parent \| prev [-]
		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.

▲

indigodaddy 5 hours ago | parent | prev [-]

“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.

▲

bobbiebarker2 5 hours ago | parent | prev | next [-]

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.

▲

tester756 6 hours ago | parent | prev | next [-]

>A compiler almost never produces a wrong output

back log of compiler's bugs can be pretty large

▲

armchairhacker 6 hours ago | parent | next [-]

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.

▲

Lerc 5 hours ago | parent [-]

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.

▲

skydhash 5 hours ago | parent [-]

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.

	▲	Lerc 3 hours ago \| parent [-]
		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.

▲

budman1 6 hours ago | parent | prev | next [-]

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.

▲

doubled112 6 hours ago | parent | prev [-]

> almost never

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

▲

qsort 6 hours ago | parent | prev | next [-]

> 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.

▲

osti 5 hours ago | parent | next [-]

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.

▲

mcv 6 hours ago | parent | prev | next [-]

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.

▲

6 hours ago | parent | prev | next [-]

[deleted]

▲

armchairhacker 6 hours ago | parent | prev | next [-]

Those are the exact concepts I was looking for.

▲

biorach 5 hours ago | parent | prev [-]

> "Algorithm" is not a word with a definition

what?

▲

qsort 5 hours ago | parent [-]

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.

▲

biorach 4 hours ago | parent | next [-]

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

▲

qsort 4 hours ago | parent [-]

> 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.

	▲	biorach 4 hours ago \| parent [-]
		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.

▲

mmarx 5 hours ago | parent | prev [-]

> 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”.

	▲	qsort 4 hours ago \| parent [-]
		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.

▲

kettlecorn 5 hours ago | parent | prev [-]

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

▲

layer8 5 hours ago | parent [-]

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.

▲

kettlecorn 4 hours ago | parent [-]

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.

	▲	layer8 4 hours ago \| parent [-]
		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.