Use planning+execution rather than one-shotting, it'll let you push back on stuff like this. I recommend brainstorming everything with https://github.com/obra/superpowers, at least to start with.
Then work on making sure the LLM has all the info it needs. In this example it sounds like perhaps your hypothetical data model would need to be better typed and/or documented.
But yeah as of today it won't pick up on smells as you do, at least not without extra skills/prompting. You'll find that comforting or annoying depending on where you stand...
Amazing how far they've got since, in just two years. As others have pointed out, it's already "boring" software in that it just works. And that's no small feat because this kind of tool requires all kinds of low-level hackery to make work, and make work fast. Hats off!
You mean what Docker for Desktop can't do? It does have a few unique features (for example automatic HTTPS for containers) but that's not the point. The point is that it's much faster, the fan runs quieter, the battery drains less, memory gets hogged less, it crashes less, the UI is smoother, the updates actually work, and it keeps improving at a steady pace. The fundamentals just work a lot better.
Right, but fetching rows along with a bunch of related rows from other tables isn't niche, it's literally the _raison d'etre_ of GraphQL (simplifying a bit because GraphQL types don't necessarily map onto db tables.)
Reminds me of Hand Cheese (Handkäse), a regional specialty popular around the Frankfurt area. It's delicious, quite pungent but with a deep flavor. It gets its name because it was traditionally formed by hand (from Quark, a harmless dairy product similar to cottage cheese). Around these parts one can expect clean hands as well, so there really is nothing untoward about the final product -- except perhaps for its name. Give it a try if you happen to be passing through!
That's hardly a convincing example. All of these points can be solved elegantly with a stream abstraction, which can be cheap or free given a sufficiently advanced language and compiler.
As for legal or policy reasons, those still aren't reasons to write boilerplate code. Your reimplementation can be tight and reuse other abstractions or include their own.
All of the examples show a single use but the value of destructuring becomes more obvious when you look at an example with multiple uses. Take this variant of one example:
Depending on what the functions are doing, neither the VM nor tsc might be able to infer that variable's value stays the same or that props, props.a, props.a.deeply, or props.a.deeply.nested will stay the same for that matter.
The VM will likely have to generate code to dereference the chain all over for the second use, and the compiler might lose narrowing information. Both of these can easily be avoided with destructuring.
(You could use "const variable = props.a.deeply.nested.variable", but then you have many of the same issues the article complains about.)
Agreed about saturation and the choice of variable name, but the code would trigger a division by zero and not result in NaN: https://go.dev/play/p/vYm4tSNEJ7M
(Also, in--say--Ruby and JavaScript 1.0/0.0 is Infinity and not NaN.)
This is a good example of why I dread Copilot: even if Go specifically couldn't express this any more concisely, there is a language that can and Copilot's very existence makes it less likely for that other language to be used as much as it deserves.
Besides, the generated example seems to be missing code to gracefully handle the case where len(filtered) is zero. Maybe there's a precondition that prevents that from happening or maybe a division by zero is exactly what you'd want, but at face value it looks like the bot did a rush job.
Reminds me of Cargolifter, they tried something less ambitious and failed... but that was 20 years ago, at the very height of the dot com boom. Better luck to the Pathfinder 3 team! It would be amazing to see airships revived.
You work with crypto according to your profile. I hope that when you see a random generator return a series of a hundred 6s, you go and check what's wrong with it instead of assuming you just got lucky this time ;-)
If you follow the link, it says Americans spend that amount of time daily with "major media", and no mention of news only. So that would presumably include reading/watching fiction, listening to music etc.?
> included are digital (online on desktop and laptop computers, mobile nonvoice and other connected devices), TV, radio, print (offline reading only), newspapers, magazines, radio, and television
Pretty big blunder in an article about media trustworthiness if you ask me.
Then work on making sure the LLM has all the info it needs. In this example it sounds like perhaps your hypothetical data model would need to be better typed and/or documented.
But yeah as of today it won't pick up on smells as you do, at least not without extra skills/prompting. You'll find that comforting or annoying depending on where you stand...