Live data from Hacker News

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

stephenramsay.net

201–210 of 626 posts

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

#201

I think you're going to need a superhuman intelligence's idea of a super-superhuman intelligence at the very least if you're going to expect C programs that are memory safe. I'll admit that I'd like to do a programming challenge with or without AI that would be like "advent of code" in assembly but if it was actual "advent of code" the direct route is to write something that looks like a language runtime system so yo…

The S-SHI would use an advanced subset of C, called "K" (after Kohut, so it's in uppercase)

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

#202
post #179

Earlier quoted context omitted.

not OP but I have a hard metric for you. AI multiplied the amount of code I committed last month by 5x and it's exactly the code I would have written manually. Because I review every line. model: Claude Sonnet 3.5/4.5 in VSCode GitHub Copilot. (GPT Codex and Gemini are good too)

I have no reason to think you're lying about the first part (although I'd point there's several ways that metric could be misleading, and approximately every piece of evidence available suggests it doesn't generalize), but the second part is very fishy. There's really no way for you to know whether or not you'd have written the same code or effectively the same code after reviewing existing code, especially when that…

> There's really no way for you to know whether or not you'd have written the same code or effectively the same code after reviewing existing code.

There is in my case because it's just CRUD code. The pattern looks exactly like the code I wrote the month prior.

And this is where LLMs excel at, in my experience. "Given these examples, extrapolate to these other cases."

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

#203

Earlier quoted context omitted.

You're describing lack of care and lack of professionalism, fire these people, nothing to do with the tools, it's the person using it the problem.

We're trying very earnestly to create a world where being careful and professional is a liability. "Move fast and break things, don't ask permission, don't apologize for anything" is the dominant business model. Having care and practicing professionalism takes times and patience, which just translate to missed opportunities to make money. Meanwhile, if you grift hard enough, you can become CEO of a trillion dollar co…

While I circumstantially agree, I hold it to be self-evident that the "optimal amount of grift is nonzero". I leave it to politicians to decide whether increased oversight, decentralization, or "solution X" is the right call to make.

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

#204

Earlier quoted context omitted.

That's what this discussion made me think of. To take it further -- if you were going to design a language expressly for AI-generated code, what might some of it's features be? I think strong static typing probably? Which is, well, not javascript in fact! (And I have bucked the trend on this previously, liking ruby -- but I'm not sure I'd want AI-generated code without it?)

Author, here. This is exactly the question I was trying (perhaps ineptly) to pose: If we designed a programming language with the idea that it would be primarily or exclusively vibe coded, what would that language look like? Might it look something more like Lean? Or more like theorem provers in general? Or would it look more like a natural language PL (think Inform 7)? Or what about a heavily declarative DSL like FA…

The problem with creating a programming language for LLMs, goes back to, what are LLMs? They are trained on masses of human written code, that is written in human readable form.

So even if you make a better programming language for a LLM, it has nothing to train on. Unless we start to transcode human language code to the LLM code.

Are the vectors/tokens/whatever, not already LLM code at this point? Technically, LLMs not are doing what Haxe was doing (haxe.org) but in a more advanced form?

Even if we make a more LLM like programming code, in a sense, we are just making another code that needs to be translated into the tokens that consist in a LLM model, no?

Feels like we are starting to hit philosophical debates with that one lol

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

#205

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…

"The guy is also a complete tool." - Who says Hackers news is not filled with humor?

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

#207

Obviously right now the best language to use LLMs for, vibe coding or not, is whatever they are most familiar with, although not sure what this actually is! Java? Going forwards, when LLMs / coding tools are able to learn new languages, then languages designed for machines vs humans certainly makes sense. Languages designed for robust error detection and checking, etc. Prefer verbosity where it adds information rathe…

Great point, except for one huge insurmountable non-technical problem with Java that can be invoked in a single word: lawnmower.

“Do not fall into the trap of anthropomorphizing Larry Ellison. You need to think of Larry Ellison the way you think of a lawnmower. You don’t anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it’ll chop it off, the end. You don’t think ‘oh, the lawnmower hates me’ — lawnmower doesn’t give a shit about you, lawnmower can’t hate you. Don’t anthropomorphize the lawnmower. Don’t fall into that trap about Oracle.” -Bryan Cantrill

“I actually think that it does a dis-service to not go to Nazi allegory because if I don’t use Nazi allegory when referring to Oracle there’s some critical understanding that I have left on the table […] in fact as I have said before I emphatically believe that if you have to explain the Nazis to someone who had never heard of World War 2 but was an Oracle customer there’s a very good chance that you would explain the Nazis in Oracle allegory.” -Bryan Cantrill

https://www.youtube.com/watch?v=-zRN7XLCRhc

Let's please not turn over the future of AI and programming languages over to a lawnmower.

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

#208

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

So in essense I have to disagree with the author's suggestion to vibe code in C instead of Python. I think the python usability features that were made for humans actually help the AI the exact same ways.

There are all kinds of other ways that vibe coding should change one's design though. It's way easier now to roll your own version of some UI or utility library instead of importing one to save time. It's way easier now to drop down into C++ for a critical section and have the AI handle the annoying data marshalling. Things like that are the real unlock in my opinion.

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

#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, and it can use type checking as an important part of verification.

If you push this idea further: use Lean, Agda or Rocq. Let the LLM solve the nitty gritty details of proof, but use the higher-level theorem formation as the vessel for doing great things.

If you ask for a Red-black tree, you get a red-black tree. If you ask for a red-black tree where all the important properties are proven, you don't have to trust the LLM anymore. The proof is the witness of correctness. That idea is extremely powerful, because it means you can suddenly lift software quality by an order of magnitude, without having to trust the LLM at all.

We currently don't do this. I think it's because proving software correctness is just 50x more work, and it moves too slow. But if you could get an amplifier (LLM) to help out, it's possible this becomes more in the feasible area for a lot of software.

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

#210

Earlier quoted context omitted.

> The agent forgets to free memory latter just like a human would and has to go back and fix it later. I highly recommend people learn how to write their own agents. Its really not that hard. You can do it with any llm model, even ones that run locally. I.e you can automate things like checking for memory freeing.

> I.e you can automate things like checking for memory freeing. Or, if you don't need to use C (e.g. for FFI or platform compatibility reasons), you could use a language with a compiler that does it for you.

Right, a lot of the promise of AI can (and has) been achieved with better tool design. If we get the AI to start writing Assembly or Machine Code as some people want it to, we're going to have the same problems with AI writing in those languages as we did when humans had to use them raw. We invented new languages because we didn't find those old ones expressive enough, so I don't exactly understand the idea that LLMs will have a better time expressing themselves in those languages. The AI forgetting to free memory in C and having to go back and correct itself is a perfect example of this. We invented new tools so we wouldn't have to do that anymore, and they work. Now we are going backwards, and building giant AI datacenters that suck up all the RAM in the world just to make up for lost ground? Weak.
Post reply on HN