But does such longevity equate to an strong, energetic life? Considering how protein intake relates to muscle and bone mass, wouldn't one rather live a little less, yet strong and kicking, rather than longer, yet thin and frail?
But if so, then where is the secret prompt sauce for getting those results, please? It's not like we complainers don't read and put in practice all we can about how to refine a spec prompt after prompt, yet our results are still disappointing. To me, that's no wonder at all, as we haven't reached AGI yet; hence, no matter how impressive and productive these tools are, I totally don't expect them to actually know what they are doing.
To be clear: LLMs write about 99% of my code, but with constant steering.
A lot of this is just talking past each other. AI being good enough to write 99% of your code but then you still complain about it sucking. Glass half full vs half empty.
Sure, but how confident can they be that it doesn't also do things they don't want?
Tests can't be exhaustive, whereas even a mediocre developer is likely to possess enough background knowledge to notice risks that a non-developer would not think to test.
Some people keep forgetting that we haven't reached AGI yet. These tools can still make serious and sometimes obvious mistakes. Not long ago, vibe-coded software could embed credentials directly. That particular blunder seems to have been addressed, but there is still no reliable way to tell an LLM to avoid every class of obvious blunder.
The un-hidden secret is that QA and real testing doesn't exist much anymore. People aren't surprised when things break, they just want it fixed quickly, and AI can do that.
Mmm... People may overlook a glitch here and there, but judging by reviews on app stores, it seems to me that people get very annoyed when things break, especially when it happens at the worst possible time.
As for AI fixing things... Sure, at least for a while. But in my experience, AI can hit a wall and start going in circles. It doesn't happen often, but it can happen. And when it does, what recourse will you have for fixing the tangled mess that vibe coding tends to produce?
P.S. Again, it all boils down to AGI not being with us yet. I guesstimate that AI writes at least 95% of my code, but given how often LLMs come up with inefficient or ineffective solutions, I'd never entrust my reputation to a vibe-coded app. Startups may have little to lose vs much to gain from a shorter time to market, but an established company?
Is that true anymore when anyone can vibe code? Seems to me that quality, correctness, and performance will be huge differentiators in a see of vibe coded slop.
Sure, but the original comment was more like “flawed solution that exists” vs “decent solution that exists”, wasn't it? That is: vibe-coding can't replace developers yet, not even mediocre ones.
> y'know you can check if an operator has been overloaded
And there lies the problem with C++: to be sure, you have to check. C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb.
Not really. C++ is on another level altogether: the code could be calling implicit conversion operators, the compiler could have instantiated some template code in an unforeseen way, and so on.
Years ago, I was really proficient in C++, but after a year of programming in C#, I realized that not once had the behavior of my code caught me off guard. In the following years, I only ran into quirky behavior a couple of times. I could finally program without the constant mental overhead of watching out for C++ pitfalls.
I suppose you're aware C# also has implicit conversion operators, operator overloading, reflection, aspect oriented programming, compiler plugins, interceptors.
Seems strange to talk down C++ while praising C#, which incidentally has been getting features to increase its use where Microsoft previously might have used C++ instead.
You catch pitfalls in any language the same way, using static analysis, which C authors introduced right in 1979, acknowledging the issues with language, which they decided to outsource to another tool, instead of improving the language.
Yes, C# is becoming more and more complex, but IMO C++ is still in a class of its own. Just compare how many different, sometimes competing ways there are to initialize variables in C++, each with its own subtleties.
I guess we'll have to agree to disagree here. And of course, even if C++'s user base seems to be shrinking, it still works well for some categories of programmers.
My favorite was the regex engine that was implemented using C++ operator overloading. The author was very proud of it, but you could not tell what code was regex code and what code was math code.
I went to some lengths with D to discourage such abusive operating overloading practice.
To the extent that one doesn't try to suppress compiler warnings & errors / actively break the language, you get what the compiler confirms is true about a function signature.
For Python, it's very little (nothing?). For Rust, you get more than most; lifetimes tell you whether it holds onto a pointer you give it.
So, Greenspun's Tenth Rule seems to have come full circle: now, "Any sufficiently complicated Coalton program contains an ad hoc, slow implementation of half of OCaml." ;)
I've left out "informally specified, bug-ridden" because I guess that's not the case for Coalton, but kept "slow" for when Coalton is used on a slower CL implementation.
There's also Armstrong's Corollary: "All sufficiently complicated distributed systems contain ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang".
