Live data from Hacker News

Claude Is Not a Compiler

blog.exe.dev

121–130 of 174 posts

Re: Claude Is Not a Compiler

#121
post #116

Earlier quoted context omitted.

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.

Re: Claude Is Not a Compiler

#122
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…

yes and if you want to code a little swimmer that explores program-space, you'll find there too!

Re: Claude Is Not a Compiler

#123
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…

flipping > to >= works quite often though!

Re: Claude Is Not a Compiler

#124

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…

You should check out Borges’, The Library of Babel . Basically if you have an infinite string of characters in some language then you have every possible book, tweet, script, scribble, and scrap of everything ever written. You just have to find it. Thats already a large universe to cover. Programs? Much bigger set.

the infinite string must have more refined properties than infinite length. an infinite string of a repeating char doesn't encode much of interest.

Re: Claude Is Not a Compiler

#125

Earlier quoted context omitted.

> Stakeholders will only give you requirements after they see the prototype. That’s very much incorrect and sounds like someone who love building more than communicating. Even without a prototype, users and other consumers will be able to explain their problems. It may not use the same metaphor map that you’re used to. But it’s very much a description of the problem space. Once you design a prototype, what you will g…

whether the hypothesis originates at the users or in your guess for the users is irrelevant in that they're both hypotheses with no certain outcome until trial.

They are. But engineering is about minimizing costs in solving a problem while ensuring requirements are met. Not worrying about costs is not engineering. It's either a research project (where you want to know if something is possible) or playing around.

Re: Claude Is Not a Compiler

#127

Nevermind "comments", has anyone with a name and reputation claimed they are?

The title is a reference back to "Is Claude Code a Compiler?" by the same author, linked from the first sentence: https://commaok.xyz/ai/is-claude-a-compiler/ And then claim is attributed right there: > The hands-down highlight was the talk by Erik Schluntz: Vibe coding in prod. > Among other things, he drew an analogy between LLMs and compilers.

Didn't read the article because the conclusion is obvoius enough to me as is, never heard of Erik Schluntz before, and drawing an analogy between two things means very little anyway. "this bike is about as heavy as that table" doesn't require the rebuttal that bikes aren't tables, for example.

so far I mostly saw it spewed forth on HN

Re: Claude Is Not a Compiler

#128
The entire "Don't Read the Code" argument is just insane to me and ironically when you see who the people are that are advocating it, it's often the same people that talked about microservices, the latest java script framework, no-code or any other methodology that was in vogue at the time just to avoid focusing on solving the real problems; The illusion that they are just one "smart step" away from achieving a 10x productivity boost that will make everything else trivial...

Re: Claude Is Not a Compiler

#129
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…

prompts are not specs because most often, prompts are underspecified. You can prompt fizzbuzz well enough for it to be functional, but not ffmpeg. So the distinction is less about Claude's capability, more about the quality of the input. Garbage in garbage out

You can reference other specs in a prompt. Video codecs are well specified with hundreds of pages of specs, they are probably in some form in the weights already, but you could also reference them and hash them as inputs directly to create a functional alternative to ffmpeg.

Re: Claude Is Not a Compiler

#130
post #129

Earlier quoted context omitted.

prompts are not specs because most often, prompts are underspecified. You can prompt fizzbuzz well enough for it to be functional, but not ffmpeg. So the distinction is less about Claude's capability, more about the quality of the input. Garbage in garbage out

You can reference other specs in a prompt. Video codecs are well specified with hundreds of pages of specs, they are probably in some form in the weights already, but you could also reference them and hash them as inputs directly to create a functional alternative to ffmpeg.

i meant to make the distinction between 'prompt' and 'spec' in that prompts are something that a human types in by hand. Interesting programs are a combination of canon and novel input
Post reply on HN