191–200 of 626 posts
> why not do it in C? Well, because you can do it in Fortran, of course! What else do you want? Multidimensional arrays out of the box, fast loops, native cuda support, trivial build and packaging system, zero version churning... all of this just with the bare language. It's the anti-python! The perfect language, you could say! Strings and i/o are a bit cumbersome, agreed, but your llm can take care of these without…
> If You’re Going to Vibe Code, Why Not Do It in C? Or assembly, or binary Yes, this is a completely valid take and it is the ultimate answer to why vibe coding, the way most people define vibe coding is a dead end. The point is we want the LLM to generate code that is first and foremost readable by humans and structured in such a way that a human can take over control at any time. If you think this is how LLM should…
python though is very readable, not so much for typescript for me.
Earlier quoted context omitted.
why even write webpages or apps anymore just prompt an LLM everytime a user makes a request and write the page to send to the user :D
This... was a Show HN a little while back, can't tell if you're making a joke or referring to that.
edit: I think i found it https://news.ycombinator.com/item?id=45783640
Earlier quoted context omitted.
That's a really, really interesting point. It makes me imagine a programming language designed for LLMs but not humans, designed for rigorous specification of every function, variable, type, etc., valid inputs and outputs, tightly coupled to unit tests, mandatory explicit handling of every exception, etc. Maybe it'll look like a lot of boilerplate but make it easy to read as opposed to easy to write. The idea of a la…
That’s what the article is about.
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 need to have lots of high-level features and structure, since those are things that exist for human comprehension.
But actually, the opposite is true. If you're designing a language for LLMs, the language should be extremely strict and wordy and inconvenient and verbose. You should have to organize your code in a certain way, and be forced to check every condition, catch every error, consider every edge case, or the code won't compile.
Such a language would aggravate a human, but a machine wouldn't care. And LLMs would benefit from the rigidness, as it would help prevent any confusion or hallucination from causing bugs in the finished software.
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.
A significant part of my LLM workflow involves having the LLM write and update tickets for me. It can make a vague ticket precise and that can be an easy platform to have discussions with stakeholders.
From time to time I have talked over a ticket with an LLM and gotten back what I think is a useful analysis of the problem and put it into the text or comments and I find my peeps tend to think these are TLDR.
Earlier quoted context omitted.
It "obviously" does based on what, exactly? For most devs (and it appears you, based on your comments) the answer is "their own subjective impressions", but that METR study ( https://arxiv.org/pdf/2507.09089 ) should have completely killed any illusions that that is a reliable metric (note: this argument works regardless of how much LLMs have improved since the study period, because it's about how accurate dev's impr…
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 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…
I just wrote a piece on this specific C issue the other day https://news.ycombinator.com/item?id=46186930