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

521–530 of 626 posts

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

#521

Post by antisthenes »

gerdesj wrote: post #374
antisthenes wrote: post #241

Earlier quoted context omitted.

Wait until you learn that most people's writing skills are that of below LLMs, so it's an actual tangible improvement (as long as you review the output for details not being missed, of course)

Hoisted by your own petard ("me old fruit"): "Wait until you learn that most people's writing skills are that of below LLMs" ... went askew at "that of below LLMs". I'm an arse: soz!

No need to apologize for a correction. That's not the culture I want to live in.

As long as you are also paying attention to the content and not just form.

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

#522

Post by javier123454321 »

jazzyjackson wrote: post #349
dlisboa wrote: post #319

Earlier quoted context omitted.

> Then I realized that this constant start-stop process is literally melting my brain and making me unable to do any real work myself. It's basically having the same effect as scrolling any other algorithmic feed Yes, it’s extremely soul sucking. With the added disadvantage of not teaching me anything.

I felt this way too until I decided that my goal isn't to know things, it's to ship things.

If your job is not to know things, just to prompt an agent to ship things, why would you have a job in a year?

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

#523

Post by javier123454321 »

a5c11 wrote: post #467
TylerLives wrote: post #175

Earlier quoted context omitted.

I don't have much experience with it either, but what has worked so far is breaking down the problem into very small steps I can verify easily.

At this point it's easier to just write the code. If my prompt is to be longer than the code produced, why bother with explaining that to LLM?

The delta between "make a small requirement that you can check and verify" vs "create the code yourself" is pretty big. A well crafted sentence can sometimes still be hours of work.

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

#524

Post by rixed »

mrweasel wrote: post #457
rixed wrote: post #408

Earlier quoted context omitted.

Are you working at OpenAI?

No, but now I'm curious about the inner workings of OpenAI.

Your comment sounded how an instance of copilot would complain to its coleagues and for a moment I pictured OpenAI being just a large scam based on an army of mechanical turks :)

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

#525

Post by luckydata »

gitremote wrote: post #230
luckydata wrote: post #217

Earlier quoted context omitted.

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

The technical design is definitely the job of the technical team for the most part, but the business requirements should be squarely on the pm. The list of use cases, how the API feels, the performance etc... All of that the business owner should be able to describe to you to ensure it does the job it needs and is fit for the market.

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

#526

Post by simlevesque »

wongarsu wrote: post #506
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 wouldn't limit it strictly to Python, but I agree that it should be limited to memory safe languages. Vibe code in C#, Rust or PHP if that suits your requirements, but C or assembly are indeed poor choices for the reasons you list

Go is perfect for this.

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

#527

Post by tome »

atilaneves wrote: post #481
ModernMech wrote: post #229

Earlier quoted context omitted.

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

I hear this about both Haskell and Rust, and yet, when I tried both in the former I wrote a useless program because I didn't handle state (and yet passed all tests!) while in the latter I immediately wrote a deadlock. So...yeah.

How did your tests pass if you didn't handle state?

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

#528

Post by 9rx »

nylonstrung wrote: post #409
9rx wrote: post #144

Earlier quoted context omitted.

> Rust has lots of checks that C and assembly don't, and AI benefits from those checks. Fil-C gets you close in the case of C, but we can ignore it because, of course, F* has significantly more checks than Rust, and AI benefits from those checks. Choosing Rust would be as ridiculous as choosing C if that was your motivation. But if you don't find the need for those checks in order to consider Rust, why not C or even…

Fil-C is way too new for LLMs to understand it and not just hallucinate back into normal C

Well, that's what the checks are for: So that hallucinations are caught by said checks and can be fed back into the LLM to ruminate on.

If you don't find importance in those checks, you wouldn't choose Fil-C anyway. But, of course, it remains that if do find those checks to be important, you're going to use a serious programming language like F* anyway.

There is really no place for Fil-C, Rust, etc. They are in this odd place where they have too many checks to matter when you don't care about checks, but not enough checks when you do care about checks. Well, at least you could make a case for Fil-C if you are inheriting an existing C codebase and need to start concerning yourself with checks in that codebase which previously didn't have concern for them. Then maybe a half-assed solution is better than nothing. But Rust serves no purpose whatsoever.

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

#529

Post by wavemode »

kesor wrote: post #348
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…

I don't think there is a need for an output language here at all, the LLM can read and write bits into executables directly to flip transistors on and off. The real question is how the input language (i.e. prompts) look like. There is still a need for humans to describe concepts for the machine to code into the executable, because humans are the consumers of these systems.

> the LLM can read and write bits into executables directly to flip transistors on and off

No, that's the problem (same misconception the author has) - it can't. At least not reliably. If you give an LLM free rein with a non-memory safe output format, it will make the exact same mistakes a human would.

The point of a verbose language is to create extensive guardrails. Which the LLM won't be annoyed by, unlike a human developer.

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

#530

Post by monegator »

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 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 an alien intelligence gets trapped in them.

First one. Most of C code you can find out there is either oneliners or shit, there are fewer bigger projects for the LLMs to train on, compared to python and typescript

And once we go to the embedded space, the LLMs are trained on manufacturer written/autogenerated code, which is usually full of inaccuracies (mismatched comments) bugs and bat practices

Post reply on HN