Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Is Not a Compiler

blog.exe.dev

Post reply on HN
Print view View original

91–100 of 174 posts

Re: Claude Is Not a Compiler

#91

Post by toonvanvr »

kloud wrote: post #62

Specs might become one solution for coping with the need to review increased volume of code. A spec is a higher level of abstraction than code, which is a higher level of abstraction than machine code. The industry made the transition to higher-level once, paradigm is changing so it might happen again. The workflow I imagine is either deriving specs from the conversation or reverse engineering the code to spec, revie…

It's funny how you describe something very close to what I was attempting to design. It was meant to trickle down from tickets to deterministic code. Data wise, it should be like a pyramid of tickets diluting layer by layer into leaf nodes which were "implementable" as statements in code. I'm not sure if that description makes sense read by someone else.

I think what made sense was envisioning a nanoswarm of LLMs (anticipating ASIC performance) diluting specs into semantic logic nodes, but a conversion from these to deterministic code made the vibe coded experiment come to halt. Your lock approach could be a shortcut to that.

Totally off-topic: it's quite intriguing that you can feel once friction starts building during a design phase. Suddenly everything slows down. I wonder if it's quantifiable and therefore can identify "wrong" design choices made by either humans or LLMs.

(Hoping some claw bot pics this up to finish my idea on my github tix repo in the initial-design branch, as main is empty ~ MPL2)

Re: Claude Is Not a Compiler

#92

Post by maweki »

chubot wrote: post #74
atomicnumber3 wrote: post #70

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…

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

Re: Claude Is Not a Compiler

#93

Post by mmarx »

qsort wrote: post #79
biorach wrote: post #63

Earlier quoted context omitted.

> "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 proc…

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

Re: Claude Is Not a Compiler

#94

Post by imagent »

gritzko wrote: 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…

A zen master asked a junior engineer to go get him a rock. The junior engineer asked what kind of rock he should get and the master replied by knocking him in the head with his cane. The junior thought for a minute, then asked, "would you like a round rock or a flat rock?" Again, the zen master rapped him on the head. The junior thought for a moment, then went to the creek and fetched a rock at random. He brought it to the zen master who inspected it and then said, "No, I want a flat piece of flint for starting a fire." The junior engineer was then enlightened.

Stakeholders will only give you requirements after they see the prototype. Thus, the spec and the prototype to elicit it are two sides to the same coin. Once the spec if correct and the prototype is starting to show its age, throw away the prototype and implement the spec with a fresh start.

Re: Claude Is Not a Compiler

#95

Post by skydhash »

Lerc wrote: post #73
armchairhacker wrote: post #41

Earlier quoted context omitted.

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.

Re: Claude Is Not a Compiler

#96

Post by keleftheriou »

encyclopedism wrote: post #67
Valodim wrote: post #46

Earlier quoted context omitted.

You say that as if it wasn't true for anything human programmers ever produced

Because Claude isn't a human the perception of it is different. Humans can fly planes, computers too can fly planes. I'm not going to give the same leeway to a 'computer' flying a plane that I would to a human. Because we understand that humans are just that, humans. The demands placed on a computer are so very different.

What about driving a car?

Computers are already driving cars autonomously, possibly better than the average human already, and quite plausibly will eventually be better than the best human driver.

Re: Claude Is Not a Compiler

#97

Post by drdexebtjl »

kloud wrote: post #62

Specs might become one solution for coping with the need to review increased volume of code. A spec is a higher level of abstraction than code, which is a higher level of abstraction than machine code. The industry made the transition to higher-level once, paradigm is changing so it might happen again. The workflow I imagine is either deriving specs from the conversation or reverse engineering the code to spec, revie…

This might work if we have completely new harnesses for this, because the current one’s intentionally introduce non-reproducible context and tools.

The current way we’re doing SDD is extremely pointless. You reach a decision point that is under specified, make a decision, update the spec and continue the implementation. There’s no guarantee that the implementation followed from the updated spec, and not from the decision.

Re: Claude Is Not a Compiler

#98

Post by kettlecorn »

layer8 wrote: post #89
kettlecorn wrote: post #78

Earlier quoted context omitted.

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 implemen…

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.

Re: Claude Is Not a Compiler

#99

Post by skydhash »

dataviz1000 wrote: post #60

Claude is more like a Probabilistic Turing Machine. [0] It's correctness isn't deterministic but rather a distribution. It is predictable. There are lots of places in computer science that determinism isn't necessarily the best. - UDP video calls let packets vanish or arrive corrupted, because waiting for retransmissions would freeze the picture. - Stochastic gradient descent picks a random mini-batch of training dat…

Determinism isn’t important, but there are usually threshold of acceptable performance in all off those cases. Machine Learning was all about improving accuracy even when you know that there’s probably an error somewhere. But the current LLM hypers refuses to acknowledge that the answer to a prompt may be wrong (even though the providers have a warning line about it).

Instead of assessing the risk and provide corrective methods, all they do is pushing to use it more and more everywhere.

Re: Claude Is Not a Compiler

#100

Post by fzeroracer »

> I’d say that, in all the ways that matter, I understand the code. Sure, if I had to hand-edit it now, there’d be a serious learning curve. But I won't have to. And more importantly, I can reason about the system, share perspectives with my colleagues, and guide agents on future work.

If there's a serious learning curve to editing code then you don't understand the code. We used to call that 'on-boarding' when you brought a new engineer on the team as they got up to speed as to how the codebase worked.

Post reply on HN