Live data from Hacker News

Claude Is Not a Compiler

blog.exe.dev

151–160 of 174 posts

Re: Claude Is Not a Compiler

#151

Earlier quoted context omitted.

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.

The cost of prototyping has dropped so much due to LLMs and coding agents that it basically always makes sense to prototype something to elicit feedback, just as part of the requirements gathering process. E.g. if you can spend $50 to understand something that will save you two weeks of effort, wouldn't you do that? That's the sort of dynamic I'm talking about.

The cost of prototyping has always been very low. I can quickly sketch a UX flow using balsamiq. Or copy-paste paste code from docs and examples to show a rough working model with. If you can extract the essence of the problem you can quickly realize cheap ways to demonstrate a solution, and not spend two weeks trying to code it.

If there’s something that is wrong with using LLMs to prototype, it is that those prototypes are always too complex. Instead of decomposing a problem and testing unrelated concerns apart from each other, it’s often a mix of everything that the LLM user had been thinking about.

Often there’s no rapid iteration where you are comparing several approaches. Instead it became tunnel vision and confirmation bias where if it’s working, that means it’s the solution.

Re: Claude Is Not a Compiler

#152
post #5

The argument being made here is really incredible when you unpack it. 1) The construction of the Empire State Building was particularly effective due to the depth of human-to-human collaboration. 2) Isn't it great that we can burn a bunch of dinosaur blood to convince ourselves that we don't need other humans?

> 2) Isn't it great that we can burn a bunch of dinosaur blood to convince ourselves that we don't need other humans?

God I hate this cynical take. Yes human beings use energy. We should look to generate more energy as that's a sign of wealth. The "energy bad" take is so lazy and ultimately anti-human. And in this case its especially obnoxious because what does "we don't need other humans" even mean.

Re: Claude Is Not a Compiler

#153
post #147
post #126

Earlier quoted context omitted.

You write code with the same level of attention you give to small talk with strangers?

Let they who has never ='d when they meant to == cast the first argument. (There's a reason why we benefit from code review).

Way to move the goalposts!

Re: Claude Is Not a Compiler

#154

I don't want to hear this ever again. No Patrick, mayonnaise is not an instrument.

it is when used to make music

Claude doesn't even make machine code though. Or it can if you really want to, but that's now how people use it. If you wanna include transpilers or interpreters, fine but the answer is still no, otherwise our git commits would just be prompts that get built either in CI or JIT. People deliver code, not prompts.

Maybe that could change some day, but even then, it wouldn't be a useful designation. It's like saying "oh technically the Americas are an island." There's a reason we still distinguish between a transpiler and compiler.

Re: Claude Is Not a Compiler

#155

Earlier quoted context omitted.

NXDOMAIN results and other errors have their own TTL value though, so if someone queries too early in the process you could be waiting a little while for their cache to check again. The value for this is set in the SOA record for your DNS zone. For example, example.org/example.com seems to have TTLs set at 300s (5 minutes) for A records, but the negative caching value is 1800s (30 minutes). If your VM domain is set t…

I always don't know enough about DNS. This is great stuff. If exe.dev is running their own DNS zone, then wouldn't they be setting the expiry value in the SOA record themselves? So they could set it to something short, and secondary servers are supposed to honor it, right?

> wouldn't they be setting the expiry value in the SOA record themselves?

If they thought about it. But it is something that even people relatively experienced in DNS matters forget about until it bites them and they've spent ages diagnosing the initially odd looking problems caused.

Re: Claude Is Not a Compiler

#156
yo dawg! I heard you like distributed services

So I made a distributed service for your distributed name service so you can distribute your names to the service that distributes them on the onternet

Re: Claude Is Not a Compiler

#158
post #144

Earlier quoted context omitted.

I was about to say a lot of algorithms or invariant bugs for me are slight mistakes at an edge of something

"There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors."

I've come to consider memory management the third

Re: Claude Is Not a Compiler

#159
Headline true, article false.

AI exists at the boundary of codification. When you understand something well enough to express it in a deterministic way, it is no longer worthwhile to keep asking AI for that thing over and over - you should codify it.

But wait, I hear you say? AI has knowledge! And we can rely on that knowledge and sprinkle on top some brief instructions and it'll get things right and work out the details itself!

That is spec driven development.

And this is great one single time. Except, knowledge shifts. You are outsourcing part of what you've codified to society as a whole, in the form of language model knowledge. You're also trusting current and future models to always produce something that meets the requirements, and never be quantized under you, and produce the same result next time despite being a probabilistic system with no memory, and and and.

Better to freeze everything in place in your codebase so you get predictable results - in other words, codify it! Let's store the desired state of that button in code in a very complicated thing that's existed for decades called a string, so it always says "Finish" and never says "Done" - even if we regenerate the app.

That's pretty unexciting and doesn't justify tens of billions of investment. Which means you won't hear it from anyone with tokens to sell. But it's what you have to do to make something people want.

Re: Claude Is Not a Compiler

#160

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

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.
Post reply on HN