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.
If you're going to vibe code, why not do it in C?
251–260 of 626 posts
Re: If you're going to vibe code, why not do it in C?
#252Vibe 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!
Re: If you're going to vibe code, why not do it in C?
#253I 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…
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?
#254I 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,…
Formal proofs have so much potential in this context
Re: If you're going to vibe code, why not do it in C?
#255Earlier 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.
Re: If you're going to vibe code, why not do it in C?
#256Vibe 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!
Re: If you're going to vibe code, why not do it in C?
#257Earlier 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…
Re: If you're going to vibe code, why not do it in C?
#258Earlier 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.
Re: If you're going to vibe code, why not do it in C?
#259I 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…
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?
#260Software 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…
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.