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

221–230 of 626 posts

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

#221

Post by psunavy03 »

badRNG wrote: post #170
giancarlostoro wrote: post #64

Earlier quoted context omitted.

I have done both strict back-end, strict front-end, full stack, QA automation and some devops as well, I worked in an all Linux shop where we were encouraged by great senior devs to always strive for better software all around. I think you're right, it mostly depends on your mindset and how much you expose yourself to the craft. I can tackle obscure front-end things sometimes better than back-end issues despite hatin…

> Speaking of vibe coding in archaic languages Well, I think we can say C is archaic when most developers write in something that for one isn't C, two isn't a language itself written in C, or three isn't running on something written in C :)

(Python has exited the chat)

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

#222

Post by vibeleaker »

zelphirkalt wrote: post #92

I very much doubt the ability of LLMs to provide leak-free, faulty memory management free, C code, because they are trained on loads of bad code in that regard. They will not output code of the quality that maybe 1% of C developers could, if even that many. Fact is, that even well paid and professional C/C++ developers introduce memory management issues in such code bases (see Chromium project statistics about this).…

I agree that an LLM may make mistakes. But one advantage is, that you can also allocate resources for it to try and find its own mistakes. You can do this humans, but the grind wears away at them. Since this doesn't really happen with an LLM, it's pretty decent at catching it's own mistakes too.

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

#223

Post by ModernMech »

hadlock wrote: post #115
zelphirkalt wrote: post #92

I very much doubt the ability of LLMs to provide leak-free, faulty memory management free, C code, because they are trained on loads of bad code in that regard. They will not output code of the quality that maybe 1% of C developers could, if even that many. Fact is, that even well paid and professional C/C++ developers introduce memory management issues in such code bases (see Chromium project statistics about this).…

He says in his article: >Is C the ideal language for vibe coding? I think I could mount an argument for why it is not, but surely Rust is even less ideal. I've been using Rust with LLMs for a long time (mid-2023?) now; cargo check and the cargo package system make it very easy for LLMs to check their work and produce high quality code that almost never breaks, and always compiles.

My favorite use for LLMs with Rust is using them as a macro debugger; they provide better error messages than the errors Cargo can provide. It's cool to take a macro and ask the LLM to do an expansion of it, to see what it would look like. Or, to take Rust code and ask the LLM to create a macro for it.

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

#224

Post by benjiro »

nphardon wrote: post #51

ive been vibe coding (i think it's vibe coding) in C for the past three weeks and it's been super fun. i was tasked with trying to improve our highly optimized hyper-graph partitioning algorithm. One of the fun things i like to do is feed the llm an academic paper, have it summarize the key pts, and then implement the algos that we (me and the llm) find interesting. This feels like i hit the fabled 10x productivity m…

I can feel ya ... Nothing more fun then vibe coding b-tree, ART, LSM, Double pointer b-tree, bw-tree, ... and so many other storage solutions relying on different indexes, compressions etc.

And having them fight it off between each other. To see where the issues are with each methode, what works better. Doing that without vibe coding the hell out of it, will take months of work, but with vibing and some cash, you do it in a few days.

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

#225

Post by godelski »

omnicognate wrote: post #118
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…

> Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. As a Professor of English who teaches programming to humanities students, the writer has had an extremely interesting and unusual academic career [1]. He sounds awesome, but I think it's fair to suggest he may not have much experience of large scale commercial software devel…

Hard to say but to back his claim that he was programming since the 90's his CV shows he was working on stuff that's clearly more than your basic undergraduate skill level since the early 2000's. I'd be willing to bet he has more years under his belt than most HN users. I mean I'm considered old here, in my mid 30's, and this guy has been programming most my life. Though that doesn't explicitly imply experience, or more specifically experience in what.

That said, I think people really under appreciate how diverse programmers actually are. I started in physics and came over when I went to grad school. While I wouldn't expect a physicist to do super well on leetcode problems I've seen those same people write incredible code that's optimized for HPC systems and they're really good at tracing bottlenecks (it's a skill that translates from physics really really well). Hell, the best programmer I've ever met got that way because he was doing his PhD in mechanical engineering. He's practically the leading expert in data streaming for HPC systems and gained this skill because he needed more performance for his other work.

There's a lot of different types of programmers out there but I think it's too easy to think the field is narrow.

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

#226

Post by ModernMech »

crazygringo wrote: post #126
stared wrote: post #5

There was a recent discussion, “Why AI Needs Hard Rules, Not Vibe Checks” ( https://news.ycombinator.com/item?id=46152838 ). We need as many checks as possible - and ideally ones that come for free (e.g., guaranteed by types, lifetimes, etc.) - which is why Rust might be the language for vibe coding. Without checks and feedback, LLMs can easily generate unsafe code. So even if they can generate C or Assembly that wor…

That's a really, really interesting point. It makes me imagine a programming language designed for LLMs but not humans, designed for rigorous specification of every function, variable, type, etc., valid inputs and outputs, tightly coupled to unit tests, mandatory explicit handling of every exception, etc. Maybe it'll look like a lot of boilerplate but make it easy to read as opposed to easy to write. The idea of a la…

I'm writing one of these, I'll post it on HN next year. The key to a language for LLMs is: make sure all the context is local, and explicit. If you have functions, use parameters for arguments instead of positions. If you have types, spell them out right there. Also, don't use too many tokens, so keywords are out. And that's just a start.

I think the ideal language for LLMs will look more like APL than C.

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

#227

Post by Yeask »

colechristensen wrote: post #151
SoftTalker wrote: post #137

Earlier quoted context omitted.

Wait until you learn that the people on the other side of your ticket updates are also using LLMs to respond. It's LLMs talking to LLMs now.

The desired result is coming to a documented agreement on an interaction, not some exercise in argument that has to happen between humans. I find having an LLM create tickets for itself to implement to be an effective tool that I rarely have to provide feedback for at all. This seems like greybeards complaining that people who don't write assembly by hand.

Who has ever complained that kids don't write assembly by hand?

Stop being outraged for things that are only real on your mind.

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

#228

Post by elif »

I would say, because time to review is the most important metric in vibe coding.

I prompt my agents to use proper OO-encapsulated idiomatic ruby paradigms. Your goal should be reduced cognitive load.

Even if you never write a line of code, you will still need to understand your problems to solve them.

"Vibe debugging" will get you stuck in loops of hallucinated solutions.

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

#229

Post by ModernMech »

vbezhenar wrote: post #174
gkfasdfasdf wrote: post #96

Earlier quoted context omitted.

Can you elaborate? What is it about Haskell that makes it better?

Very advanced type system which allows to move a lot of program correctness to typing system. So basically if your program compiles, it probably works. It's also has GC which makes it better suited for most programs, compared to Rust with its manual memory management.

Rust does not have manual memory management, and its type system also has the property that if your program compiles it probably works, IME.

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

#230

Post by gitremote »

luckydata wrote: post #217
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.

I've been doing API development for over ten years and worked at different companies. Most PMs are not technical and it's the development team's job figure out the technical specifications for APIs we build. If you press the PMs, they will ask the engineering/development manager for the written technical requirements, and if the manager is not technical, they will assign it to the developers/engineers. Technical requirements for an API are really a system design question.
Post reply on HN