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 know the language because you're going to need to amend the code. Therefore vibe in the language you know. Anyone that suggests that AI can produce a solid application on its own is a fraud.
If you're going to vibe code, why not do it in C?
31–40 of 626 posts
Re: If you're going to vibe code, why not do it in C?
#32I'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?)
Re: If you're going to vibe code, why not do it in C?
#33Software 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, they will dodge you, and if you ask front-end or web developers, they are waiting for you to provide them the API. The hardest part is understanding the requirements. It's not because of illiteracy. It's because software development is a lot more than coding and requires critical thinking to discover the requirements.
Re: If you're going to vibe code, why not do it in C?
#34Do it in Ada, SPARK, Zig, Rust, Pascal, Crystal, etc.
Unless it's an existing project where migration is too costly, C is just entering a time wasting pact along with a lot of other people that like suffering for free.
Re: If you're going to vibe code, why not do it in C?
#35This 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.
Re: If you're going to vibe code, why not do it in C?
#36When building cli and infrastructure tools and using AI my goto is go. Pardon the pun.
Re: If you're going to vibe code, why not do it in C?
#37There 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…
Why Rust? Haskell is gold standard here.
Re: If you're going to vibe code, why not do it in C?
#38There’s a nugget of an idea in there, even if I disagree with most of it. But code doesn’t only need to be understood for maintenance purposes: code is documentation for business processes. It’s a thing that needs to be understandable and explainable by humans anytime the business process is important. LLMs can never / should never replace verifiability, liability, or value judgment.
Agree with your point. It's going to be super interesting to see whether languages become more lower or higher on the stack. My guess is unuseful: both.
We've not really seen what impact this will have just yet.
Re: If you're going to vibe code, why not do it in C?
#39> Or hell, why not do it in x86 assembly? Because I want to be able to review it, and extend it myself. edit: Pure vibe coding is a joke or thought exercise, not a goal to aspire to. Do you want to depend on a product that has not been vetted by any human? And if it is your product, do you want the risk of selling it? I can imagine a future where AI coders and AI QA bots do all the work but we are not there yet. Besi…
We could go to the semantic road and proclaim that if you extend it yourself, it's not "pure" vibe coding.
I'm getting too old for this shit.
Re: If you're going to vibe code, why not do it in C?
#40Software 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.