Live data from Hacker News

Claude’s C Compiler vs. GCC

harshanu.space

241–250 of 377 posts

Re: Claude’s C Compiler vs. GCC

#241
post #95

Earlier quoted context omitted.

however it's something entirely different for that output to be good and maintainable People aren't prompting LLMs to write good, maintainable code though. They're assuming that because we've made a collective assumption that good, maintainable code is the goal then it must also be the goal of an LLM too. That isn't true. LLMs don't care about our goals. They are solving problems in a probabilistic way based on the c…

> People aren't prompting LLMs to write good, maintainable code though. Then they're not using the tools correctly. LLMs are capable of producing good clean code, but they need to be carefully instructed as to how. I recently used Gemini to build my first Android app, and I have zero experience with Kotlin or most of the libraries (but I have done many years of enterprise Java in my career). When I started I first ha…

> Then they're not using the tools correctly. LLMs are capable of producing good clean code, but they need to be carefully instructed as to how.

I'd argue that when the code is part of a press release or corporate blog post (is there even a difference?) by the company that the LLM in question comes from, e.g. Claude's C compiler, then one cannot reasonably assert they were "not using the tools correctly": even if there's some better way to use them, if even the LLM's own team don't know how to do that, the assumption should be that it is unreasonable to expect anyone else to how to do that either.

I find it interesting and useful to know that the boundary of the possible is a ~100kloc project, and that even then this scale of output comes with plenty of flaws.

Know what the AI can't do, rather than what it can. Even beyond LLMs, people don't generally (there's exceptions) get paid for manually performing tasks that have already been fully automated, people get paid for what automation can't do.

Moving target, of course. This time last year, my attempt to get an AI to write a compiler for a joke language didn't even result in the source code for the compiler itself compiling; now it not only compiles, it runs. But my new language is a joke language, no sane person would ever use it for a serious project.

Re: Claude’s C Compiler vs. GCC

#242
Building a C compiler is definitely hard for humans, but I don’t think it’s particularly strong evidence of "intelligence" from an LLM. It’s a very well understood, heavily documented problem with lots of existing implementations and explanations in the training data.

These kinds of tasks are relatively easy for LLMs, they’re operating in a solved design space and recombining known patterns. It looks impressive to us because writing a compiler from scratch is difficult and time consuming for a human, not because of the problem itself.

That doesn’t mean LLMs aren’t useful, even if progress plateaued tomorrow, they’d still be very valuable tools. But building yet another C compiler or browser isn’t that compelling as a benchmark. The industry keeps making claims about reasoning and general intelligence, but I’d expect to see systems producing genuinely new approaches or clearly better solutions, not just derivations of existing OSS.

Instead of copying a big project, I'd be more impressed if they could innovate in a small one.

Re: Claude’s C Compiler vs. GCC

#243

Can someone explain to me, what’s the big deal about this? The AI model was trained on lots of code and spit out sonething similar than gcc. Why is this revolutionary?

If someone told you 5 years ago that a computer generated a working C compiler, would you think it was a big deal or not?

[dead]

Re: Claude’s C Compiler vs. GCC

#244
post #167
post #39

Earlier quoted context omitted.

I'm reminded, once again, of the recent "vibe coded" OCaml fiasco[1]. The PR author had zero understanding why their entirely LLM-generated contribution was viewed so suspiciously. The article validates a significant point: it is one thing to have passing tests and be able to produce output that resembles correctness - however it's something entirely different for that output to be good and maintainable . [1] https:/…

I'm humbled by the maintainer's answer [0]. Must be great to work with people like him who have infinite patience and composure. [0] https://github.com/ocaml/ocaml/pull/14369#issuecomment-35565...

Yes, that comment by gasche is a very good general explanation for why vibe coded slop still doesn't cut it for contributing to any non-trivial FLOSS project. When you're building towards a large feature (DWARF support in this case) it's critical for contributions to be small and self-contained so that maintainers and reviewers don't get overwhelmed. As things stand, this means that human effort is an absolute requirement.

When contributions are small and tightly human-controlled it's also less likely that potential legal concerns will arise, since it means that any genuinely creative decisions about the code are a lot easier to trace.

(In this case, the AI seems to have ripped off a lot of the work from OxCaml with inconsistent attribution. OxCaml is actually license compatible (and friendly) with Ocaml but obviously any merge of that work should happen on its own terms, not as a side effect of ripoff slop code.)

Re: Claude’s C Compiler vs. GCC

#245
This is a conjecture: modern chips are optimized to make the output code style of GCC/Clang go fast. So, the compilers optimize for the chip, and the chip optimizes for the popular compilers.

Re: Claude’s C Compiler vs. GCC

#246

Gcc and clang are part of the training set, the fact that it did as bad as it did is what’s shocking

There are lots of C compilers (LCC, TCC, SDCC, an army of hobby projects C compilers) available as open-source.

I am curious about what results would be for something like a lexer + parser + abstract machine code generator generation for a made up language

Re: Claude’s C Compiler vs. GCC

#247
post #30

Earlier quoted context omitted.

This to me sounds a lot like the SpaceX conversation: - Ohh look it can [write small function / do a small rocket hop] but it can't [ write a compiler / get to orbit]! - Ohh look it can [write a toy compiler / get to orbit] but it can't [compile linux / be reusable] - Ohh look it can [compile linux / get reusable orbital rocket] but it can't [build a compiler that rivals GCC / turn the rockets around fast enough] - T…

> the insane rate of progress Yeah but the speed of progress can never catch the speed of a moving goalpost!

The goalpost is not moving. The issue is that AI generates code that kinda looks ok but usually has deep issues, specially the more complex the code is. And that's not being really improved.

Re: Claude’s C Compiler vs. GCC

#248

Earlier quoted context omitted.

In my experience, it is often the other way around. Enthusiasts are tasked with trying to open minds that seem very closed on the subject. Most serious users of these tools recognize the shortcomings and also can make well-educated guesses on the short term future. It's the anti crowd who get hellbent on this ridiculously unfounded "robots are just parrots and can't ever replace real programmers" shtick.

Maybe if AI evangelists would stop lying about what AI can do then people would hate it less. But lying and hype is baked into the DNA of AI booster culture. At this point it can be safely assumed anything short of right-here-right-now proof is pure unfettered horseshit when coming from anyone and everyone promoting the value of AI.

Your comment is a perfect example of the biases I'm talking about. "AI evangelists" are not a singular group of people.

Re: Claude’s C Compiler vs. GCC

#249
post #80

Earlier quoted context omitted.

As an Anti, my argument is "if AI will good in future, then come back in the future"

As a pro, my argument is "it's good enough now to make me incredibly productive, and it's only going to keep getting better because of advancements in compute". I'd rather get really good at leveraging AI now than to bury my head in the sand hoping this will go away. I happen to agree with the saying that AI isn't going to replace people, but people using AI will replace people who don't. So by the time you come back…

it sure is possible that One person using AI effectively may replace 10 people like me. it is just as likely that i may replace 10 people who only use AI.

Re: Claude’s C Compiler vs. GCC

#250

Earlier quoted context omitted.

All these people that built GCC and evolved the language did not have the end result in their training set. They invented it. They extrapolated from earlier experiences and knowledge, LLMs only ever accidentally stumble into "between unknown manifolds" when the temperature is high enough, they interpolate with noise (in so many senses). The people building GCC together did not only solve a to technical problem. They…

That's true and I fully agree. I don't think LLMs' progress in writing a toy C compiler diminishes the achievements that the GCC project did. But also we've just witnessed LLMs go from being a glorified line auto-complete tool to it writing a C compiler in ~3 years. And I think that's something. And noting how we keep moving the goal post.

GP: "it didn't write a C compiler, it copied other compilers. Writing one from scratch is a lot harder."

You: "but look! It wrote a C compiler!"

Post reply on HN