Live data from Hacker News

Claude Is Not a Compiler

blog.exe.dev

161–170 of 174 posts

Re: Claude Is Not a Compiler

#162

I've heard something along the lines of "Claude is like a compiler: source code is the new object code, you don't look at that anymore" many times. And I don't really think this is true. Compilers are usually deterministic, and whilst we can find edge cases, it's nothing like an AI agent writing all the code for you. I think you have two choices, given the Claude is a code generator and not a compiler: (a) you review…

Part of the value of LLMs and humans is nondeterminism. Pair nondeterministic output with strictly verified results (proper tests) and you can create a useful working system.

Humans can't build a system perfectly, and agents definitely can't. And agents (like humans) will build a different system every time even with the same prompt. Even if it's just trivial differences like array vs linked-list, there are still differences.

The value in having executable code is that it won't change its behavior unless you deliberately modify it. I don't think there are any shortcuts. Models will get smarter and smarter and make fewer mistakes, but you'll still want to produce real source code to execute because it's consistent (you can sell it as a product, set it and forget it, etc.), and most importantly:

running real code is orders of magnitude faster than having an AI either run the process "manually", or have it write the code out multiple times.

Re: Claude Is Not a Compiler

#163

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

[flagged]

Re: Claude Is Not a Compiler

#164
post #112

Earlier quoted context omitted.

Something I have always (even pre-LLMs) found funny to think about is - all code possible to run on a computer already exists. It's some permutation of all the bits of available memory. It's in there somewhere. So, suppose you want a specific program. 1. Some huge % of those possible programs are obviously not the one you want (most don't even compile). 2. Remaining programs might look similar to the one you want, bu…

One of my professors used an example like this to encourage you to pause if you ever find yourself doing something like "maybe if I just flip this the tests will pass". The space of incorrect programs (even ones that pass your tests) is enormous compared to the space of correct programs. If you like thinking about this and haven't seen this before, check out the busy beaver problem[1]. [1]: https://en.wikipedia.org/w…

I remember the Computer Recreations column in Scientific American on busy beavers back in 1984. I was too young then to really appreciate it. (I really miss that column—and the Amateur Scientist.)

I found it here (page 19) https://wkbpic.com/wkbx/SA/1984/1984-08-01.pdf

Re: Claude Is Not a Compiler

#165
post #55

LLM-is-a-compiler is indeed a simplistic approach. I wrote a rebuttal to the yesterday's Cursor post, may reuse it here https://replicated.live/blog/follow-up The idea that a 835-page spec "just exists" and we run an LLM to implement it is completely flawed. Specs do not appear out of nowhere, they co-evolve with the code. If you have the code, why do you want to generate it again? Good software is made as a product…

Something I have always (even pre-LLMs) found funny to think about is - all code possible to run on a computer already exists. It's some permutation of all the bits of available memory. It's in there somewhere. So, suppose you want a specific program. 1. Some huge % of those possible programs are obviously not the one you want (most don't even compile). 2. Remaining programs might look similar to the one you want, bu…

I've thought similarly about music before. Everything's there in white noise. To get music you just have to selectively remove parts of it.

Re: Claude Is Not a Compiler

#167
post #11

I'll go a step further and say Claude is an Interpreter. It even has just-in-time compilation: it can directly follow a spec and generate small snippets live. I'm pretty sure we'll soon see services (admittedly highly inefficient) built on Claude-as-a-backend.

words have meaning

Re: Claude Is Not a Compiler

#168
post #92
post #74

Earlier quoted context omitted.

all code possible to run on a computer already exists. It's some permutation of all the bits of available memory. It's in there somewhere This seems either mathematically impossible or vacuous, depending on what you mean ...

I think the intent is clear. We could just enumerate all strings in size and lexicographical order. Then the task is only to filter, which strings are programs we desire. It's the same sentiment as "the typing itself is not the issue, it's the order of the button presses that's difficult." Of course, by Rice's theorem, all interesting questions are undecidable anyway...

If we restrict ourselves to programs that can be stored inside the physical universe, suddenly everything switches from undecidable to O(1) :)

Re: Claude Is Not a Compiler

#169

Earlier quoted context omitted.

I think something can be considered a spec to some degree if outcome was derived from it. It might underspecify, but that is just a quality of the spec. And as long as there is any discretion at implementation time, then the spec necessarily underspecifies to some degree. The goal of a spec is often to be clear on key directional concerns. Consider RFCs. There's a trade-off between specification and implementation di…

and LLMs are really good at filling in the blanks. It's like a really big import on generic application knowledge, and if you draw the circles well enough, it will draw the rest of the owl.

[deleted]

Re: Claude Is Not a Compiler

#170

Earlier quoted context omitted.

>A compiler almost never produces a wrong output back log of compiler's bugs can be pretty large

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.

>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

Post reply on HN