Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If you're going to vibe code, why not do it in C?

stephenramsay.net

Post reply on HN
Print view View original

211–220 of 626 posts

Re: If you're going to vibe code, why not do it in C?

#211

Post by hu3 »

Havoc wrote: post #106
wilg wrote: post #94

If you're vibe coding, I highly recommend TDD. It makes it very easy for a coding agent to iterate on it. You gotta bonk it sometimes when it tries to delete a problematic test etc, but hallucinating a test suite along with your app really helps a lot. (I've been vibe coding a scripting language/compiler for a video game project I'm working on in this way, and it's been fascinating and mostly great.)

Do you write the test yourself or get the agent to do it?

No OP but I also guide LLMs with TDD and it's a mixture of LLMs write tests for happy paths and I write tests for edge cases.

Also when I use LLM to fix a bug, I tell it to write a test to prevent regression of the bug at the end of the session, after the bug is fixed.

Re: If you're going to vibe code, why not do it in C?

#213

Post by jesse__ »

chis wrote: post #208
markstos wrote: post #105

I have successfully vibe-coded features in C. I still don't like C. The agent forgets to free memory latter just like a human would and has to go back and fix it later. On the other hand, I've enjoyed vibe coding Rust more, because I'm interested in Rust and felt like my understanding approved along they way as I saw what code was produced. A lot of coding "talent" isn't skill with the language, it's learning all the…

It's really funny how much better the AI is at writing python and javascript than it is C/C++. For one thing it proves the point that those languages really are just way harder to write. And another thing, it's funny that the AI makes the exact same mistakes a human would in C++. I don't know if it's that the AI was trained on human mistakes, or just that these languages have such strong wells of footguns that even a…

I don't think it has much to do with the languages being harder .. the training sets for JS and Python are probably an order of magnitude larger.

Re: If you're going to vibe code, why not do it in C?

#214

Post by BiteCode_dev »

- C takes a lot more context than a high-level language

- a lot of C code out there is not safe, so the LLM outputs that

- C encodes way less of the programmer's intention, and way more implementation details. So unless the author is extremely good at naming, encapsulating and commenting, the LLM just has less to work with. Not every C code is Sqlite/redis/ffmeg quality.

- the feedback loop is slower, so the LLM has less chance to brute force a decent answer

- there is no npm/pypi equivalent for C on which to train the LLM so the pool for training is less diverse

- the training pool is vastly Linux-oriented, with the linux kernel and distro system libs being very prominent in the training data because C programs on Windows are often proprietary. But most vibe coders are not on Linux, nor into system programming.

Sure, you can vibe code in C. Antirez famously states he gets superb ROI out of it.

But it's likely you'll get even better results with other languages.

Re: If you're going to vibe code, why not do it in C?

#215

Post by lowsong »

> Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong.

This is such a bad take. I'm convinced that engineers simply don't understand what the job is. The point was never "does it output code that works", the point is "can it build the right thing in a way that is maintainable and understandable". If you need an LLM to understand the output then you have failed to engineer software.

If all you're doing is spitting out PoCs and pure greenfield development then I'm sure it looks very impressive, as the early language models did when it looked like they were capable of holding a conversation. But 99% of software engineering is not that kind of work.

Re: If you're going to vibe code, why not do it in C?

#216

Post by rmsaksida »

sramsay wrote: post #145
jrochkind1 wrote: post #32

Earlier quoted context omitted.

That's what this discussion made me think of. To take it further -- if you were going to design a language expressly for AI-generated code, what might some of it's features be? I think strong static typing probably? Which is, well, not javascript in fact! (And I have bucked the trend on this previously, liking ruby -- but I'm not sure I'd want AI-generated code without it?)

Author, here. This is exactly the question I was trying (perhaps ineptly) to pose: If we designed a programming language with the idea that it would be primarily or exclusively vibe coded, what would that language look like? Might it look something more like Lean? Or more like theorem provers in general? Or would it look more like a natural language PL (think Inform 7)? Or what about a heavily declarative DSL like FA…

Unrelated - it looks like your blog's RSS feed isn't up to date. :-)

Re: If you're going to vibe code, why not do it in C?

#217

Post by luckydata »

gitremote wrote: post #33

Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. I work in backend, API development, which is completely different from fullstack development with backend development. If you ask PMs about backend requirements, th…

Sounds like you work with inexperienced PMs that are not doing their job, did you try having a serious conversation about this pattern with them? I'm pretty sure some communication would go a long way towards getting you on a better collaboration groove.

Re: If you're going to vibe code, why not do it in C?

#218

Post by benjiro »

nu11ptr wrote: post #76
raphlinus wrote: post #71

There's a straightforward answer to the "why not" question: because it will result in codebases with the same kind of memory unsafety and vulnerability as existing C code. If an LLM is in fact capable of generating code free of memory safety errors, then it's certainly also capable of writing the Rust types that guarantee this and are checkable. We could go even further and have automated generation of proofs, either…

It is also equally odd to me that people want to cling so hard to C, when something like Rust (and other modern languages for that matter), have so much nicer eco systems, memory safety aside. I mean C doesn't even have a builtin hashtable or vector, let alone pattern matching, traits and sum types. I get this is about AI and vibe coding, but we aren't at a point yet where zero human interaction is reasonable, so eve…

> It is also equally odd to me that people want to cling so hard to C, when something like Rust (and other modern languages for that matter), have so much nicer eco systems, memory safety aside.

Simplicity? I learned Rust years ago (when it was still pre release), and when i now look at a lot of codebases, i can barely get a sense what is going on, with all the new stuff that got introduced. Its like looking at something familiar and different at the same time.

I do not feel the same when i see Go code, as so little has changed / got added to it. The biggest thing is probably generics and that is so rarely used.

For me, this is, what i think, appeals for C programmers. The fact that the language does not evolve and has been static.

If we compare this to C++, that has become a mess over time, and i know i am getting downvoted for this, Rust feels like its going way too much in the Rust++ route.

Like everybody and their dog wants something added, to make Rust do more things, but at the same moment, it feels like its repeating the C++ history. I have seen the same issue with other languages that started simple, and then becomes monsters of feature sets. D comes to mind.

So when you see the codebase between developers, the different styles because of the use of different feature sets, creates this disconnect and makes it harder for people to read other code. While with C, because of the language limits, your more often down a rather easier way to read the same code. If that makes sense?

Re: If you're going to vibe code, why not do it in C?

#219

Post by porksoda »

cujo wrote: post #122
gitremote wrote: post #112

Earlier quoted context omitted.

My company mandates AI usage and logs AI usage metrics as input to performance evaluation, so I use it every day. It's a Copilot subscription, though.

why though? are they just using it as a proxy for "is 'gitremote' working today?"

The first time i asked it about some code in a busy monorepo and it said "oh bob asked me to do this last week when he was doing X, it works like Y and you can integrate it with your stuff like Z, would you like to update the spec now?"... I had some happy feelings. I dont know how they do it without clobbering the context, but it's great.

Re: If you're going to vibe code, why not do it in C?

#220

Post by teach »

wavemode wrote: post #196

> if vibe coding is the future of software development (and it is), then why bother with languages that were designed for people who are not vibe coding? Shouldn’t there be such a thing as a “vibe-oriented programming language?” VOP. A language designed for vibe coding could certainly be useful, but what that means is the opposite of what the author thinks that means. The author thinks that such a language wouldn't n…

Sounds like Ada. A lot of the time, once you got your code to compile, it would work.
Post reply on HN