Thank you!
That's exactly what it is. Instead of presenting you 1000 results (or 0) which you have to manually skim through, it generates 1 result as a summary. And even if there is no actual search result, it will hallucinate you 1 result (full of BS).
But because the result sounds right (and in cases with good data it actually is) people tend to trust it. I do not dismiss the potential, but for me the line is crossed when you take the result for granted without verifying and while I'm sure many here think that is implied, I bet you, at large, it is not and will be even less so in the future.
Remember the OOP Hype 20 years ago? I'm still cleaning shit up from then in our codebase when everyone used patterns after skimming through the GoF book without even knowing why ....
My prediction is in 20 years I will clean up the shit that was co-authored by Claude ...
And there's nothing "wrong" with the GoF Patterns per-se. The issue was always people applying them blindly without understanding why (or more to the point, "if") they were needed. Once writing code filled with patterns became "the thing you do"... all bets were off. :-(
I remember putting stuff like this on my resume "developed X using visitor pattern" . ppl would ask "what is your favourite design pattern" in interviews. lmao.
I do have a favourite (couple of) design pattern(s)
SOLID
and
Hexagonal Programming
But these are not GoF patterns (although Singleton's are, and I do recall how it was incredibly difficult to produce a singleton in some languages - eg. Python)
The idea that a lot of people have in their heads is that if the code doesn't fit the need, you'll just start over completely with a fresh codebase, because it's so fast to generate it.
In other words, there won't be 20-year-old code in this future.
We'll see if that comes to pass, but there's a lot of money betting that will happen; enough to where people will disregard what the downsides are.
I'm a german software developer working for a japanese corporation in a german subsidiary. I agree with pretty much everything in your post. Especially the exhausting chain of approvals and also the unwillingness to make quick/tough decisions feels like walking through molasses at times.
However, there is also an upside to this. I can actually confirm that they take quality control very serious, probably due to the losing face cultural thing if the product fails the customer and therefore rarely do quick last minute changes or crunch, because it degrades quality.
I worked for a software consulting company in Japan, we had a contract with a big well known company. The contract gave a precise date for the delivery with huge fines if we delivered late but there was also a long bug fixing period after the initial delivery.
So we had overtime for 2 months working from 10am to 4am just so that we could deliver the "feature complete" software. If any bugs were found they were classified as either blockers (feature cannot be shown without) or scheduled to be fixed after delivery.
My boss knew it was stupid, he didn't like it but it was the standard contract from that big Japanese company and we were small and they weren't going to change that.
As a fan of Nintendo (the games, not the company of course), this definitely checks out. There are exceptions, but you rarely see a new Zelda game release in the state you can expect from Bethesda.
I've been selfhosting for like dunno 10-15 years. Cheap kimsufi box, opensmtp, dovecot, later then rspamd, done. Never really had a problem. At one point telekom.de blocked my mailserver. I contacted them via postmaster@telekom.de (or something) explaining that while kimsufix boxes are notorious for shady stuff, this is actually a legit mailserver and they whitelisted me shortly after (yeah I was surprised too how smooth that went). So, yeah, can't confirm all the troubles everyone seems to get on about. However I do own the kimsufi box (and the corresponding IP) for a long time now, so maybe I'm just lucky.
Fully agree.
Also, jq exists, a simple example how open and simple interfaces (text streams) allow for extensibility. There is a reason why so much is built on top of "simple terminals".
> That means you have a mix of FORTRAN, ada, c, rust, some custom internal corporate language, and so on all mixed with the C++. If your build system cannot handle that mess i'm not interested
In that case I would just use the rust toolchain which I'm sure can handle this stew.
I'm using C/C++, which do provide a good level of type safety.
And no, types are absolutely not my problem. In fact, rigid type systems are a frequent source of practical problems, and they often shift the game to one where you're solving type puzzles -- instead of working on the actual functionality.
Come on, dude. C provides almost no type safety whatsoever. There’s no point in saying “C/C++” here, because you won’t adopt the C++ solutions for making your code actually typesafe.
Type safety is not a standardized term, and it is not binary. Being black and white about things is almost always bad. One needs to weigh and balance a large number of different concerns.
A lot of "modern C++" is terrible, terrible code precisely because of failing to find a balance.
But because the result sounds right (and in cases with good data it actually is) people tend to trust it. I do not dismiss the potential, but for me the line is crossed when you take the result for granted without verifying and while I'm sure many here think that is implied, I bet you, at large, it is not and will be even less so in the future.
Brave New World!