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

141–150 of 174 posts

Re: Claude Is Not a Compiler

#141

Post by Lerc »

skydhash wrote: post #95
Lerc wrote: post #73

Earlier quoted context omitted.

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.

Have a go at writing something in 1975's C.

x=-5 Is not x = -5

There's no unsigned int.

It's a better comparison to the usability of Claude than you might think. It's doable, but hardly ideal.

Re: Claude Is Not a Compiler

#142

Post by nunez »

> exe.dev VMs have nice domain names: vm-name.exe.xyz. When we start a new VM, we add a CNAME entry or three. Easy, right?

> But our VMs start fast, so fast that even if we created the DNS entries before creating the VM, our users still had to sit around waiting for DNS to propagate, which occasionally took minutes, not seconds.

> We did the obvious thing: We wrote our own DNS server, so that DNS always immediately matched the source of truth. And life was good.

> But latency matters, so we added regions. And just like that, DNS became the long pole again, because all DNS was served out of Oregon. Also, deployments caused tiny DNS outages. To fix this, all we needed now was a geographically distributed but fully consistent DNS server.

> We did what a sensible engineer does when faced with a hard problem: cheat. We vibe-engineered a distributed DNS server tuned to our specific needs.

I'm sure they have already considered this, but what problem does this solve that couldn't be solved by using dnsmasq, unbound or something like that? Why reinvent the wheel?

Re: Claude Is Not a Compiler

#143

Post by philipwhiuk »

nunez wrote: post #142

> exe.dev VMs have nice domain names: vm-name.exe.xyz. When we start a new VM, we add a CNAME entry or three. Easy, right? > But our VMs start fast, so fast that even if we created the DNS entries before creating the VM, our users still had to sit around waiting for DNS to propagate, which occasionally took minutes, not seconds. > We did the obvious thing: We wrote our own DNS server, so that DNS always immediately m…

That doesn't require vibe-coding, which is what they are selling as the solution to every problem.

Re: Claude Is Not a Compiler

#144

Post by oblio »

lilbigdoot wrote: post #133
Xmd5a wrote: post #123

Earlier quoted context omitted.

flipping > to >= works quite often though!

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

Re: Claude Is Not a Compiler

#145

Post by oblio »

atomicnumber3 wrote: post #70
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…

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…

Reality is a fractal (Mandelbrot?) and this is where LLMs will help science. They will help us explore the fuzzy edges faster. LLMs probably won't find new "leaves", but they should be able to cover a lot of useful but "boring" fuzz.

Re: Claude Is Not a Compiler

#146

Post by tpetry »

nunez wrote: post #142

> exe.dev VMs have nice domain names: vm-name.exe.xyz. When we start a new VM, we add a CNAME entry or three. Easy, right? > But our VMs start fast, so fast that even if we created the DNS entries before creating the VM, our users still had to sit around waiting for DNS to propagate, which occasionally took minutes, not seconds. > We did the obvious thing: We wrote our own DNS server, so that DNS always immediately m…

The question is more what this really solves. They said they built all this because DNS propagation was too slow. But secondary dns servers by e.g. your isp will still have old records when you change something. So what did they earn? Every is correct within their network pretty fast. But for a normal user there isnt any difference because 8.8.8.8 or 1.1.1.1 still cache old records?

Re: Claude Is Not a Compiler

#147

Post by ben_w »

miyoji wrote: post #126
ben_w wrote: post #26

Earlier quoted context omitted.

"thanks, you too"

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

Re: Claude Is Not a Compiler

#148

Post by imagent »

skydhash wrote: post #125
kimjune01 wrote: post #119

Earlier quoted context omitted.

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.

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.

Re: Claude Is Not a Compiler

#149

Post by QuercusMax »

lilbigdoot wrote: post #134
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…

I think this is a great abstraction of the process I've never considered in those terms and I like it. It explains a bit of how software development differs from some other building processes where the desired outcome is being discovered as you figure out how to make something that produces that outcome

There are plenty of processes that have this property, though. For example: setting up a home, workspace, kitchen, factory, office, etc. to fit a particular purpose. As you discover what works well in a particular space, you will refactor your workflows, seating organization, storage systems, etc to fit what you're doing. And it may even have multiple valid configurations - for example seasonal variations like outdoor vs indoor areas.

Re: Claude Is Not a Compiler

#150

Post by Merad »

atomicnumber3 wrote: post #70
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…

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…

> It's some permutation of all the bits of available memory. It's in there somewhere.

True, but the number of possible permutations is so large it's incomprehensible. Let's limit ourselves to say a 50 MiB program, meaning the size of the compiled binary. If I'm remembering the math correctly, that amount of memory can hold 2^(2^20 * 50 * 8) different states. That's 2^419430400 or roughly 10^126000000. For comparison, the heat death of the universe is predicted to occur in about 10^100 years, or 10^107 seconds. You'd need to be able to look at more than a million programs per second to examine them all before the end of the universe.

Post reply on HN