lelele

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.

This.

> If you never use "naked pointers" and always use std::unique_ptr and std::shared_ptr, will it not reduce nearly all memory related bugs?

It will, as long as the code uses them correctly all the time, including when refactoring. In the end, that's still manual memory management.

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.

I definitely hope so!

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?

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?

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.

Joel On Software: Rewriting software is the single worst strategic mistake that any software company can make. [1]

Microsoft: Take that, Joel!

;)

---

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Indeed. I'm trying to develop a similar style. The phrasing in the quoted passage is really tight.

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.

See my reply to a similar objection: https://news.ycombinator.com/item?id=48520416

See my reply to a similar objection: https://news.ycombinator.com/item?id=48520416

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.

> 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.

In my experience, yes. AFAICS, LLMs never think out of the box, and are heavily influenced by the way you ask questions.

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.

Would you mind sharing your HW configuration? Thank you.

You forgot the 10 levels of precedence and the 3 associativity options for operators ;)

> The main difference between my workflow and the authors, is that I have the LLM "write" the design/plan/open questions/debug/etc. into markdown files, for almost every step. > > This is mostly helpful because it "anchors" decisions into timestamped files, rather than just loose back-and-forth specs in the context window.

Would you please expand on this? Do you make the LLM append their responses to a Markdown file, prefixed by their timestamps, basically preserving the whole context in a file? Or do you make the LLM update some reference files in order to keep a "condensed" context? Thank you.

> Sure sounds like another fad diet.

Yeah! A fad lasting millions of years of human evolution, however.

Thank you very much for taking the time to reply.

With the crucial difference that now you have some leeway in firing one/some of your bosses.

Thanks for sharing. Would you mind expanding on a few points?

> 2. sell what makes customers feel good buying

What did you have in mind? What would make a purchase feel good or bad for a customer?

> 3. Never compete, focus on service with a novel niche product. Stupid people by their nature destroy everything around them regardless of long term benefit.

I'm not sure how the second sentence connects to the first - could you clarify what you mean there?

> 9. Stay quiet (especially online in a sea of cons), and only talk about the distant past when people try to goad you into telling them how you make revenue

You mean staying quiet about the specifics of your current products and strategy, as opposed to sharing general advice like here, right?

> Never let technical staff talk with the customers, or vendors.

Could you elaborate on the reasoning behind this?

Thanks again.

I don't know about others, but I switched to Reddit or forums for asking and answering questions because it offered a much smoother experience.

What do you mean?

.

There is no such thing as "desktop Linux". What we have instead is a large collection of distros, each with its own UX, unlike Windows or macOS which present a relatively unified platform.

I switched to Linux many years ago because a new laptop was unusably slow under the Windows Vista it came with, and I have not looked back since, yet I'd never recommend Linux to "the masses". Linux can work well for people who just browse the web and read email. Beyond that, the experience quickly becomes dependent on having a knowledgeable person nearby to help with choosing software and supported hardware or troubleshooting it.

To me, articles like this show how disconnected many technically inclined people are from average users' experience. Things like bloated software or aggressive advertising may be annoying to us, but to most users they are just part of using a computer.

- AI Chat in VS Code

- ChatGPT Web interface