The problem’s not so much that the posters are AI generated, but that they’re too crowded and unfocused.
Their individual elements seem fine and look good, but when taken as a whole they feel wrong.
This may be a failure mode similar to juniors using AI and making it much harder for seniors to find the bugs, because the code actually looks good at first sight.
I don’t think the blog author actually has any design skills based on the prompts and the AI obviously can’t nudge them in the right direction or help them clarify their brief, like a real designer (i.e. not random online freelancers) would.
The set-up and your reply feel like a Rust sketch.
Not touching a codebase only applies to legacy software which is feature complete.
Any actively developed software will benefit from incremental improvements.
Quality C++ projects continuously improve their code and tooling. It would be very convenient for the rustafarian community if the competition stood still, but that’s not the case. Quite happy to see that golang’s also providing solid opposition.
Note that an incremental language improvement doesn't mean a small code change. For example, C++'s iterator with two related but technically independent pointers is a PITA for alias analysis, which is a problem not only for Circle/Safe C++ but for WG21 Profiles too (https://www.circle-lang.org/draft-profiles.html). An incremental language change would be to adopt a Rust-like iterator. That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.
Bjarne still sees C++'s safety problem as lack of adoption of Modern C++. WG21 is catering to C++ users who will not make such changes.
WG21 has firmly rejected everything resembling Rust's borrow checking (a solution that now has a decade of proven track record, and has been demonstrated to be possible in C++ via Circle/Safe C++). Addition of "pervasive annotations" is so unacceptable to WG21's view of C++ that they're still insisting on Profiles.
“Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched.”
That was most of your original comment and it remains wrong.
Now you’re talking about specific memory-safety-related features, but you’re making a big assumption. Not everything has to look like Rust. Goodness no! And C++ is still improving in that area too.
“An incremental language change would be to adopt a Rust-like iterator.”
One of many possibilities.
“That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.”
Obviously not. Nowadays maybe it could be easily done with AI, even if a Rust-like iterator is not necessarily something that C++ programmers would want.
Don’t believe everything you read. Any communication from them is a PR exercise.
On the other hand, I read an interesting substack blog from an ex-Azure employee the other day: the Russinovich-dictated Rust rewrite was allegedly vaporware for a long time and caused lots of headaches that were not widely known. A highlight for me was the use of over 1000 third party crates in their products.
Would be interesting to know how it’s going nowadays.
As any company, the one I work for also has its decent share of rustafarians. The Rust penetration is modest and slow, but the PR is remarkable.
It’s useful for DIY, but definitely not great. One has to carefully double-check everything; there’s no unit-tests to save your butt.
It can help out with understanding tools, workflows, materials, etc but doesn’t actually understands what it’s writing about and is prone to over-engineering, making critical mistakes or just replying with nonsense (for example swapping dimensions, recommending a completely inappropriate procedure, the wrong tool, etc).
This is all with Opus and Sol. Paying 22€ per month for that is a bit pricy for what one gets in return.
Even their absolute high-end stuff is at best particle board with veneer. And you can bet the back will still be that thin 3mm fiberboard, no matter how high-end they look.
Unfortunately, top models nowadays have more and more hollow panels.
Seems to me that quality’s going down and they’re trying to save money with the materials they offer. But they can still be a good enough compromise, as I found out when looking for e.g. a TV sideboard.
The wood types are clearly labeled, so its not something they are trying to hide. And i'm not sure why hollow panels in itself are necessarily a bad thing...cutting down on material without hurting design or functionality has plenty of benefits (environmental, weight, cost).
For chests of drawers and bookcases they have one configurable wood product.
All the storage solutions for the living room are tiny and almost all of them are made of unstained pine.
For wardrobes they have two products, one of which is open and looks bad and the other’s tiny.
There are no wood equivalents to Pax, Platsa or Besta, the Ikea workhorses with a modern design.
And even if they existed, I don’t think people would rush to buy them. Solid wood’s not what Ikea’s known for and would cost too much for their target market.
I’m not saying they’re bad - I own several of their products, and while I’m overall pleased with them, I don’t love them. The compromises and cost-cutting design choices are always there if you know what to look for.
None of my Ikea furniture brings me joy or makes me want to touch it. It’s functional and looks decent to good.
Hollow panels are too light, not robust enough and essentially unrepairable. One could buy some Ikea pieces and cut them / adapt them in irder to upgrade them. These panels make that impossible.
In my experience, those that can’t understand design in the small (code level) don’t understand it in the large (sw or systems architecture) either.
Doing the right thing for the customer is independent from good design and good code. It’s a problem of requirements and project management.
This is an excuse some poor programmers use, that they can’t write good code, but at least they fulfilled the customer requirements :D
Getting everyone to understand the problems, working together, etc, etc are issues that are inherent to organisations.
They’re orthogonal to AI and to the actual hard technical skills needed to execute on a specific strategy. And if the technical skills are lacking, it doesn’t even matter how good an organisation is at collaboration, whereas hard skills plus organisational disfunction are a known successful pattern :)
Many people did look at this through an individual lens and claimed that design skills, domain knowledge are the truly important abilities. I remember reading on HN at least a couple of popular articles claiming that.
Actually, they’re all important and having great design skills without matching coding skills is IMO not really possible. The code feeds into the design, the requirements, the architecture and shapes them.
I don’t disagree. I’ve worked on teams that definitely valued the non-coding skills more and it showed in their inability to deliver on certain requirements… mainly performance and stability.
But these are skills that can be taught to individuals.
But teaching an organization that their real bottleneck isn’t how fast they’re writing code; it’s producing production-ready software that people understand and are willing to take responsibility for… that’s much harder.
Many businesses want to treat software development like an assembly line and revert back to Taylorism. It’s knowledge work and there’s no royal road. Good teams get fast when they have the right mix of skills and trust from the organization.
What we’ve been delving into for the last decade has been a decline in the value of labour and work.
“Code isn’t the hard part,” isn’t meant as an insult at individual programmers or to devalue their work. That’s being done by big tech and their AI hype machine.
Real designers would avoid them in the first place.
reply