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.
Claude Is Not a Compiler
121–130 of 174 posts
Re: Claude Is Not a Compiler
#122LLM-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…
Re: Claude Is Not a Compiler
#123Earlier 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…
Re: Claude Is Not a Compiler
#124Earlier 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.
Re: Claude Is Not a Compiler
#125Earlier 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.
Re: Claude Is Not a Compiler
#126Re: Claude Is Not a Compiler
#127Nevermind "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.
so far I mostly saw it spewed forth on HN
Re: Claude Is Not a Compiler
#128Re: Claude Is Not a Compiler
#129Specs 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
Re: Claude Is Not a Compiler
#130Earlier 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.