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

531–540 of 626 posts

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

#531

Post by pmarreck »

awesome_dude wrote: post #127
skydhash wrote: post #107

Earlier quoted context omitted.

Because LLMs will have no concept of that IL. It only have a model for what it has seen.

100% People are still confusing AI putting together scraps of text it has seen that correlates with its understanding of the input, with the idea that AI understands causation, and provides actual answers.

And people are also still clearly confusing "isn't human or conscious" with "can't possibly create new logical thoughts or come to new logical conclusions i.e. do intellectual labor" when there is a plethora of evidence at this point that the latter is, in fact, the truth

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

#532

Post by swiftcoder »

> Wouldn’t a language designed for vibe coding naturally dispense with much of what is convenient and ergonomic for humans in favor of what is convenient and ergonomic for machines? ... surely Rust is even less ideal.

I don't get how the second follows from the first. One of the main complaints levelled against Rust is that it is not ergonomic for humans, specifically because it forces you to work to a set of restrictions that benefit the machine.

With an LLM coding agent that quickly produces volumes of somewhat-scattershot code, surely we're better off implementing incredibly onerous guardrails (that a human would never be willing to deal with)?

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

#533

Post by fny »

> Or hell, why not do it in x86 assembly?

Or greater hell, why not binary?

If we ignore human readability (as the author suggests), the answer is context. The token count explodes as you fall down the abstraction rabbit hole. Context consumption means worse reasoning.

In turn, this means expressiveness matters to LLMs just as much as it matters to us. A functional map reduce can be far simpler to write and edit than an imperative loop. Type safety and borrow checking free an LLM from having to reason about types and race conditions. Interpreted languages allow an LLM to do rapid exploration and iteration. Good luck with live reloading a GUI in C.

And if you were to force the LLM to do all that in C, at some point it might decide to write its own language.

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

#534

Post by swiftcoder »

xxs wrote: post #503
godelski wrote: post #225

Earlier quoted context omitted.

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

> I'm considered old here, in my mid 30 That's absolutely not true. It was awkwardly funny to read that.

I've been the oldest guy on several teams in row now, starting in my early 30s. FAANG/startup culture skews very young

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

#535

Post by 0xbadcafebee »

throwforfeds wrote: post #517
0xbadcafebee wrote: post #293

Earlier quoted context omitted.

If it needs that many rules, why use AI at all? Linters pre-exist AI, don't cost money, and don't boil the oceans. Look at Shellcheck. It turns a total newbie into a shell master just by iteration.

I find it's really nice to just have Claude run the compilers and linters when it's done making a change, as it often has some mistakes and will catch them at this step. It lets me step in for review after some trivially stupid thing is fixed up, rather than wasting my own time.

I'm starting to believe other people have a very different experience from me. I use AI to write Terraform. It "fixes" things I don't want "fixed", changes the functionality I wanted, disobeys restrictions I gave it, etc. About half of the time, my time is wasted.

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

#536

Post by Gud »

swiftcoder wrote: post #532

> Wouldn’t a language designed for vibe coding naturally dispense with much of what is convenient and ergonomic for humans in favor of what is convenient and ergonomic for machines? ... surely Rust is even less ideal. I don't get how the second follows from the first. One of the main complaints levelled against Rust is that it is not ergonomic for humans, specifically because it forces you to work to a set of restric…

Agreed. Seems to me that for vibe coding you want 1) prevent as many run time errors as possible at compile time ( Rust )

2) use a language that is well supported by the community with countless examples ( Python )

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

#537

Post by mentos »

wongarsu wrote: post #509
mentos wrote: post #491

Earlier quoted context omitted.

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.

I don't think we will ever reach the same accuracy simply because some languages are harder than others. Writing correct C (not just "working C") is difficult because of the number of footguns and the amount of reasoning and implicit state tracking you have to do in your head. LLMs are not free from this, if anything that's harder for them. Meanwhile languages like Java are more difficult just because they are verbos…

Yea agreed, by C I really meant 'low level'. If as an industry we had to support a language under Python, Rust is probably it.

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

#538

Post by pmarreck »

skydhash wrote: post #107
pmarreck wrote: post #100

At that point, why not develop a custom language or IL that is specifically designed for LLM use and which compiles to good native code? I propose WASM, or an updated version of it

Because LLMs will have no concept of that IL. It only have a model for what it has seen.

It is trained on WASM btw, but if we invented one specific for it, it could easily be trained up on it or refined with it. I've already had some success just handing it a language guide and it runs with it.

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

#539

Post by btbuildem »

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 bigger bottleneck to productivity is that very few people can correctly articulate requirements.

One could argue that "vibe coding" forces you (eventually) to think in terms of requirements. There's a range of approaches, from "nitpick over every line written by AI" to "yolo this entire thing", but one thing they have in common is they all accelerate failure if the specs are not there. You very quickly find out you don't know where you're going.

I see this in my work as well, the biggest bottleneck is squeezing coherent, well-defined requirements out of PMs. It's easy to get a vision board, endless stacks of slides about priorities and direction, even great big nests of AWS / Azure thingnames masquerading as architecture diagrams. But actual "this is the functionality we want to implement and here are the key characteristics of it" detail? Absolutely scarce.

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

#540

Post by paulddraper »

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 the bottleneck is good PMs then.

Which is what vibe coders are.....

Post reply on HN