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

491–500 of 626 posts

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

#491

Post by mentos »

Danborg wrote: post #486

Vibe coding should be done in Python, and probably only in Python. If a project is important enough to require C or x86 assembly, where memory management and undefined behavior have real consequences, then it’s important enough to warrant a real developer who understands every line. It shouldn’t be vibe coded at all. Python’s “adorable concern for human problems” isn’t a bug here, it’s a feature. The garbage collecti…

I'm really curious to see if Python will maintain this lead in the future or if all languages will catch up to the same level of accuracy.

If not then I see the argument for everything being done in Python and performance coming from optimizing Python -> C.

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

#492

Post by MattRix »

Danborg wrote: post #486

Vibe coding should be done in Python, and probably only in Python. If a project is important enough to require C or x86 assembly, where memory management and undefined behavior have real consequences, then it’s important enough to warrant a real developer who understands every line. It shouldn’t be vibe coded at all. Python’s “adorable concern for human problems” isn’t a bug here, it’s a feature. The garbage collecti…

Ok but what happens when you reach the point where the LLM makes fewer mistakes than the human? Where it’s better at spotting potential memory corruption and security holes?

It doesn’t feel like we’re very far from that point.

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

#493

Post by IshKebab »

atilaneves wrote: post #483
IshKebab wrote: post #141

Earlier quoted context omitted.

> Rust doesn't prevent programs from having logic errors. Nobody ever claimed that. The claims are: 1. Rust drastically reduces the chance of memory errors. (Or eliminates them if you avoid unsafe code.) 2. Rust reduces the chance of other logic errors. Rust doesn't have to eliminate logic errors to be a better choice than C or assembly. Significantly reducing their likelihood is enough.

Every language with a GC drastically reduces the chance of memory errors.

Yeah and I would say they're probably a better choice for vibe coding than C!

But most of them don't have a nice strong type system like Rust. I have vibe coded some OCaml and that seems to work pretty well but I wouldn't want to use OCaml for other reasons.

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

#494

Post by gbin »

sureglymop wrote: post #259
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…

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 ef…

Shouldn't we try vibe coding on IR then? Basically assembly before compiler optimizations?

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

#495

Post by sdiupIGPWEfh »

pron wrote: post #238
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…

The thing is that some imagined AI that can reliably produce reliable software will also likely be able to be smart enough to come up with the requirements on its own. If vibe coding is that capable, then even vibe coding itself is redundant. In other words, vibe coding cannot possibly be "the future", because the moment vibe coding can do all that, vibe coding doesn't need to exist. The converse is that if vibe codi…

Following similar thinking, there's no world in which AI becomes exactly capable of replacing all software developers and then stops there, miraculously saving the jobs of everyone else next to and above them in the corporate hierarchy. There may be a human, C-suite driven cost-cutting effort to pause progress there for some brief time, but if AI can do all dev work, there's no reason it can't do all office work to replace every human in front of a keyboard. Either we're all similarly affected, or else AI still isn't good enough, in which case fleets of programmers are still needed, and among those, the presumed "helpfulness" of AI will vary wildly. Not unlike what we see already.

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

#497

Post by awelkie »

What the author is describing is the logical conclusion of the Bitter Lesson applied to software development. To quote the essay: "We have to learn the bitter lesson that building in how we think we think does not work in the long run." The author of this article correctly points out that a lot of what goes into programming language design is a model of how humans think, and a lot of the abstractions are there to make it easier for humans to reason about code. That's not to say that abstraction isn't useful for machines, but I think the bitter lesson would say that it's better in the long run to let the machine figure out the best abstractions through search, and let humans think in the way they're used to thinking: in natural language.

Now personally I don't think this ultimate vibe-coding paradigm is just around the corner, but it does seem that it's the direction we're heading and I think this article does a good job of explaining why.

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

#498

Post by sfdlkj3jk342a »

Danborg wrote: post #486

Vibe coding should be done in Python, and probably only in Python. If a project is important enough to require C or x86 assembly, where memory management and undefined behavior have real consequences, then it’s important enough to warrant a real developer who understands every line. It shouldn’t be vibe coded at all. Python’s “adorable concern for human problems” isn’t a bug here, it’s a feature. The garbage collecti…

> The moment you need C’s performance or assembly’s precision, you’ve crossed into territory that demands human accountability.

I disagree. I write a lot of one-off numerical simulations where something quick and dirty is useful but performance matters and the results can be easily verified without analyzing every line of code. Python would be a terrible choice.

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

#499

Post by littlestymaar »

awelkie wrote: post #497

What the author is describing is the logical conclusion of the Bitter Lesson applied to software development. To quote the essay: "We have to learn the bitter lesson that building in how we think we think does not work in the long run." The author of this article correctly points out that a lot of what goes into programming language design is a model of how humans think, and a lot of the abstractions are there to mak…

> let humans think in the way they're used to thinking: in natural language

Writing a program means stating unambiguously what you want, but natural language is ambiguous which is why legalese exists.

So you need to have an unambiguous source language for what's end up being executed by your machine (which is what programming languages are), otherwise you have no way of knowing if the machine does what you want it to do.

Of course you can use an LLM to translate natural language to unambiguous language, but at the end of the day you must read the generated language because that's the only way to dispel the fundamental ambiguity of the natural language.

I saw a webcomic ten years ago where a project manager discussing the future automation of programmer's jobs:

PM: “In the future, there will be no developers, just project manager. We will just give the machines very complete and precise specifications and it will make the software on its own. Without needing you”.

Dev: “You know how we call a "very complete and precise specification"? It's called code”.

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

#500

Post by Maxion »

Danborg wrote: post #486

Vibe coding should be done in Python, and probably only in Python. If a project is important enough to require C or x86 assembly, where memory management and undefined behavior have real consequences, then it’s important enough to warrant a real developer who understands every line. It shouldn’t be vibe coded at all. Python’s “adorable concern for human problems” isn’t a bug here, it’s a feature. The garbage collecti…

Am I the only one who feels like this is the output of an LLM?

A poorly written comment by a human wastes time. A vibe comment by an LLM wastes both time and electricity that only shows up when global warming reaches 3c.

The question isn't if the comment is valuable or not. It's whether it is ethical or not to waste peoples time with AI slop.

This is chatGPTs pattern.

Post reply on HN