Using e.g. a single zettabit-sized look-up table to give the 64-bit result of a multiplication of two 32-bit numbers suffers from a similar problem. But if we're talking about practical concerns there are already faster methods than random access in >100 exabytes of memory. And if we're talking theoretical concerns your answer still hasn't addressed the question of how to multiply numbers fast.
Regardless, if the problem is an input that normally registers the state of a button except for noise for some time as it bounces when it transitions, 48 of those reads, the averaging and the 5ms latency that incurs are unnecessary with respect to the problem.
An averaging filter makes sense if you have a noisy analog input. For a button input that registers whether it is pressed or not except for a known noise around transitions specifically, ignoring the transitions immediately after the first one registered is not only faster (both in terms of latency and CPU cost) but easier to implement. It's also equally practical for switches with long bounce, where the time it would take for an average to favor a transition might be impractically long.
Writing the compiler and standard library in Zig is probably the greatest dog fooding opportunity for the Zig maintainers. In doing so they get to feel the weight of every change they make to the language, for as long as they don't simply hand that task over to a chatbot.
It's also an open source project, so the end product is as much the codebase as it is the binary releases.
I've interacted enough with largely computer generated codebases to see that ergonomics problems easily grow and accumulate when LLMs remove the burden of dealing with those problems from the developer. I've always considered my laziness an asset. Now I would qualify that by saying that laziness is an asset for as long as it compels you to keep things simple and easily understandable so that the cost of making changes (whether that's measured in human gray hairs or tokens) doesn't grow with every change.
I imagine that if/if-else as expressions and then necessarily their bodies as expressions would entail a much more fundamental change to the language. You then have to think of a way for the bodies to indicate a result. That, or you have to make a special case for if/else sequences where the bodies are bare expressions, in which case you've just invented the ternary operator.
Zig and Rust have addressed the problem of how the result of a block expression should be presented, but neither solution seems particularly satisfying to me.
In Rust, blocks may end with an expression, giving them a non-void result. But a block may also end in a statement, the only difference being that the statement ends in a semicolon, in which case the expression still has the void result, and I think that semicolon being the only difference makes it hard to scan at a glance where values come from.
In Zig, blocks may give non-void results by `break`ing out of them with an expression. But break normally ignores blocks and break out of loops only, so to break out of blocks you have to provide a label for it and give that when you break so as to break out of the named block and not the outer loop, e.g. `const x = label: { break :label 35; }`. That creates a problem of one of the most difficult classes in software engineering: naming things. Ideally I think `break` from a block should have its own keyword, e.g. `const x = { give 35; }`
I can't imagine that making the differences between the languages more subtle would improve the performance of chatbots. Subtleties aren't their strong suit.
The original claim was that "at eight they have limited comprehension of the world around them and limited language skills" and that they can't conduct debate is a relevant example of that.
Deciding on a product design that's easily marketable is also a marketing problem.
You suggest adding it as a "bonus", but for whom? Recording what on the walk? How would you advertise that along the main feature people actually buy the thing for? If not, what purpose does it serve? It's a few cents, but that's still a few cents too much if that's not what you're convincing people to buy.
Try to think of someone who didn't buy a walkman because it lacked a recording feature. What's their story? Can that easily be represented in the marketing material?
They seem attracted to sliced bread in plastic bags here in the Nordics. They attach to the end of the bag so as to seal and hold it closed, regardless of the labeling on the bag.
There are some positive side effects to this, which is probably the reason we're so tolerant of their presence.
Unskilled people are not irrelevant if you intend on working with other people, in which case you will need to deal with them in one way or another.
I will probably be dealing with them in the future more than in the past because chatbots bypass the process by which unskilled people generally become skilled people.
Chatbots enable unskilled developers to go in way out of their depth with little resistance. This creates problems of a new nature, not just more problems of the same nature as before.
Previously in my career, a junior making a mistake and being told why it was a mistake would learn from that and improve. The junior-chatbot duo will not. The junior will feed my comment into the chatbot, and the chatbot will superficially give the impression of having learned from the mistake and fix the code while introducing the same problem somewhere else, and the junior will have learned nothing.
This all requires that I review code as though it was created by some kind of cursed monkey's paw with an endless number of fingers that each grants a wish of the operator with a devastating caveat through idiotic interpretation.
If you give a toddler who can otherwise not operate a chainsaw -- for the simple reason that they don't have the strength to start it using the starter rope -- access to a robot who will turn on the chainsaw for them on command, you've created a problem which didn't exist before.
If you quietly patch the vulnerable software it's unlikely that I will ever hear about the vulnerability. CVE disclosure is important because that's how I learn of security problems in software I critically depend on. It's not merely a service to the maintainers, but to the users who might otherwise critically depend on vulnerable software.
So this is is intended to smooth over the poor work, bad commit hygiene and bad commit messages of "agents", presumably not meaning just any agent but LLM-based ones specifically.
I can already see the change. What I need to know is why, not how exactly. It should be clear from a commit message why a change was made. If it's not, that problem should be addressed during review. I shouldn't have to watch a recap of your conversation with a virtual idiot to understand your commit. If the tools you use to generate code can't be coaxed into producing that level of quality, or if you don't understand the output of your generative tools to the extent that you can describe for someone else why they made a particular change, you have a tooling and competency problem.
If further tooling can solve these problems, then I'm all for it, but the idea here seems to be to not solve that problem, but to burden anyone interrogating the history of a repository with also scrolling through chat histories so that virtual idiots can keep shitting out low-quality changes and so that operators can keep accepting those changes as-is without thinking too much about why.
I guess it doesn't help that tools like GitHub don't really care about commit messages. You can't even comment directly on commit messages during review.