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

41–50 of 626 posts

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

#41

Post by codyb »

erichocean wrote: post #35
barrister wrote: post #31

This author, like many others on this site, seem to imply that AI generates "good" code, but it absolutely does not---unless he's running some million dollar subscription model I'm unaware of. I've tested every AI using simple Javascript programs and they all produce erroneous spaghetti slop. I did discover that Claude produces sufficiently decent Haskell code. The point is that the iterative process requires you kno…

> I did discover that Claude produces sufficiently decent Haskell code. Clojure generation is also very solid. Gemini Pro 2.5/3 is fantastic at it. A part of me wonders if that is because these languages primarily have senior devs writing code, so the entire training set is "good" code.

The Erlang space vs the Elixir space (can't speak for agent based code generation here) would seem to give credence to this theory.

When I would explore Elixir forums with much larger communities there'd be myriad base level questions with code blocks written as if Elixir and Ruby were interchangable cause the syntax looks similar and thus missing out on many of the benefits of OTP.

But when you'd go to the Erlang community to ask a question, half the time the author of the book or library was one of the like... 20 people online at any given moment, and they'd respond directly. The quality of the discussions was of course much deeper and substantial much more consistently.

I have not tried to generate Elixir vs Erlang code but maybe it'd be a neat experiment to see if the quality seems better with Erlang

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

#42

Post by d-lisp »

naths88 wrote: post #23

I have been coding as an autodidact for 20 years now. In the past months, I have been vibe coding a lot, with multiple AIs at the same time. I have achieved to code a full webapp (React and Next.js for the front, RestJS for the back) in five days. Refactoring, adding features and writing the right tests for everything to work has been procuring me with the same problem solving and endorphin kicks as usual programming…

Do you have a link to the webapp you produced or its source code ?

edit: it was a real request, I was being interested, not some mockery or idk

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

#43

Post by treyd »

xandrius wrote: post #24

Alright, the whole article stands on the lifting done by the concept of "vibe coding", which is not just asking an LLM to write some code, scan it quickly to check if it at least makes somewhat sense and then accept it. It is based on pure vibe coding, where the user literally has no idea what's being produced. After having understood the context, I still believe that a strongly typed language would be a much better…

Claude Code is pretty good at Rust, but it works best if there's a pre-existing structure built by a human that it's operating within. Rust's error messages give rich context and are designed for humans, so it's able to figure out how to resolve its mistakes from them in ways that it simply would have to grind through in tests with trial and error in dynamic languages. And then when you do write unit tests to address logic bugs, it's able to leverage the rich context from the type system to write decent tests.

I wouldn't trust it to reliably write safe C though. It works in Rust because there's meaning embedded into the types that are checked by the compiler that gives it feedback when it makes mistakes. But you don't get that in C.

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

#44

Post by tatjam »

jrochkind1 wrote: post #32
fantasizr wrote: post #27

I've wondered what vibe codings impact is to language development, whereas C vs LISP had their tradeoffs when deciding what to use. If everything is vibecoded (not saying it will be) everything probably normalizes to javascript

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?)

Lean 4 seems to be pretty AI-usable, and you get insane guarantees (but LLM do seem to make very heavy use of "sorry")

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

#45

Post by gitremote »

bildiba wrote: post #14

I started reading this out of curiosity, thinking: that's such a far fetched thought, I'm curious about what the author wants to say. I think he makes a good point about execution vs. readability, and the actual need for the latter, drawing analogies to earlier abstractions. I'm still skeptical about low level language generation (tbh, letting an LLM handle memory at this point of maturity feels scary to me.. leaks e…

I believe they are arguing against vibe-coding categorically by pointing out that high-level programming languages are for human expression. It's a reductio ad absurdum against the logical conclusion that follows from vibe coding as a premise. If vibe coding is like a using a compiler, why not just translate English directly to machine code or lower level languages?

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

#47

Post by jcelerier »

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…

To be honest I've never worked in an environment that seemed too complex. On my side my primary blocker is writing code. I have an unending list of features, protocols, experiments, etc. to implement, and so far the main limit was the time necessary to actually write the damn code.

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

#48

Post by pfbtgom »

Many of the “no” comments here are very focused on the current state. The author seems to be looking at a longer time horizon of computing paradigms, for example invoking ENIAC. On that scale I tend to agree. Vibe coding has only been around a year or two and look how big of an impact it already has. Imagine what another 10 years of progress will look like.

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

#49

Post by jmull »

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…

Rust doesn't prevent programs from having logic errors.

If LLMs produce code riddled with bugs in one language it will do in other languages as well. Rust isn't going to save you.

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

#50

Post by bjacobso »

mavamaarten wrote: post #40
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…

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.

Claude Code et al. asks clarifying questions in plan mode before implementing. This will eventually extend to jira comments
Post reply on HN