Live data from Hacker News

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

stephenramsay.net

251–260 of 626 posts

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

#251

Earlier quoted context omitted.

I just wrote a piece on this specific C issue the other day https://news.ycombinator.com/item?id=46186930

well,glib is terrible for anything important, it's really just for desktop apps. when there is a mem error, glib does not really handle it,it just aborts. ok for desktop, not ok for anything else.

I addressed this in the first sentence of the second post (g_try_malloc) in a direct reply to my original post: https://news.ycombinator.com/item?id=46186931

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

#252

Vibe Coding is just a stepping stone to No Coding. No one (other than computer people) wants computers and software, they want results. This generation of AI will be used to bootstrap the next generation of AI. Programmers getting excited about vibe coding is like candlemakers getting excited about installing electric lights in their shops, so they can make more candles!

Or a stepping stone to starting a lighting company. The nature of programming changes when implementation can be automated. That still leaves higher level concerns like design and architecture.

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

#253

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…

Something I've noticed that I never really see called out is how easy it is to review rust code diffs. I spent a lot of my career maintaining company internal forks of large open source C programs, but recently have been working in rust. The things I spent a lot of time chasing down while reviewing C code diffs, particularly of newer team members, is if they paid attention to all the memory assumptions that were non-local to the change they made. Eg. I'd ask them "the way you called this function implies it _always_ frees the memory behind that char*. Is that the case?" If they didn't know the answer immediately I'd be worried and spend a lot more time investigating the change before approving.

With rust, what I see is generally what I get. I'm not worried about heisenbug gotchas lurking in innocent looking changes. If someone is going to be vibe coding, and truly doesn't care about the language the product ends up in, they might as well do it in a language that has rigid guardrails.

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

#254
post #209

I think you should use a language with a highly expressive type system. That can be assembly too. See TAL back from the 1990'es. I also think you should use a language with a very expressive module system. The reason is that you want to have some kind of guidance from a larger perspective in the long run. And that is exactly what types and module systems provide. The LLM has to create code which actually type checks,…

Lean would be so well suited to LLMs. I hope we see a resurgence in interest in languages like that

Formal proofs have so much potential in this context

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

#255
post #227

Earlier quoted context omitted.

Who has ever complained that kids don't write assembly by hand? Stop being outraged for things that are only real on your mind.

Speaking of things that are only real in your mind... Am I outraged? And yes, there absolutely was a vocal group of a certain type of programmer complaining about high level languages like C and their risks and inefficiency and lack of control insisting that real programmers wrote code in assembly. It's hard to find references because google sucks these days and I'm not really willing to put in the effort.

You made it up, that is why you can't find it.

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

#256

Vibe Coding is just a stepping stone to No Coding. No one (other than computer people) wants computers and software, they want results. This generation of AI will be used to bootstrap the next generation of AI. Programmers getting excited about vibe coding is like candlemakers getting excited about installing electric lights in their shops, so they can make more candles!

Many programmers became programmers because they love technology and vibe coding is about the coolest technology we've seen in a long time.

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

#257

Earlier quoted context omitted.

Yup. I would never be able to give my Jira tickets to an LLM because they're too damn vague or incomplete. Getting the requirements first needs 4 rounds of lobbying with all stakeholders.

We had a client who'd create incredibly detailed Jira tickets. Their lead developer (also their only developer) would write exactly how he'd want us to implement a given feature, and what the expected output would be. The guy is also a complete tool. I'd point out that what he described wasn't actually what they needed, and that there functionality was ... strange and didn't actually do anything useful. We'd be told…

Every time I've received overly detailed JIRA tickets like this it's always been significantly more of a headache than the vague ones from product people. You end up with someone with enough tech knowledge to have an opinion, but separated enough from the work that their opinions don't quite work.

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

#258

Earlier quoted context omitted.

If AI doesn't make you more productive you're using it wrong, end of story. Even if you don't let it author or write a single line of code, from collecting information, inspecting code, reviewing requirements, reviewing PRs, finding bugs, hell even researching information online, there's so many things it does well and fast that if you're not leveraging it, you're either in denial or have ai skill issues period.

Not to refute your point but I’ve met overly confident people with “AI skills” who are “extremely productive” with it, while producing garbage without knowing, or not being able to tell the difference.

They just shovel the garbage on someone else who has to fact check and clean it up.

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

#259

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…

Lately I have learned assembly more deeply and I sometimes let an AI code up the same thing I did just to compare.

Not that my own code is good but every single time assembly output from an optimizing compiler beats the AI as it "forgets" about all the little tricks involved. However it may still be about how I prompt it. If I tell it to solve the actual challenge in assembly it does do that, it's just not good or efficient code.

On the other hand because I take the time to proof read it I learn from it's mistakes just as I would from my own.

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

#260

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…

I constantly run into issues where features are planned and broken down outside-in, and it always makes perfect sense if you consider it in terms of the pure user interface and behaviour. It completely breaks down when you consider the API, or the backend, is a cross-cutting concern across many of those tidy looking tasks and cannot map to them 1:1 without creating an absolute mess.

Trying to insert myself, or the right backend people, into the process, is more challenging now than it used to be, and a bad API can make or break the user experience as the UI gets tangled in the web of spaghetti.

It hobbles the effectiveness of whatever you could get an LLM to do because you’re already starting on the backfoot, requirements-wise.

Post reply on HN