Now remove the spacebar, combine the two buttons into a single one for "tone" and adapt it to morse code. All the buttons still do only one thing and now there's only one button!
And, you don't have to worry about what to do in the case that someone hits the "rotate ball" button while it's still rotating.
Why remove the code and binary artifacts, though? Don't you want to verify that the business logic is accurate and the processing is deterministic?
In some circumstances there is no substitute for something that you know will produce the same answer for a given input, consistently. And that's before even considering the watts per response.
Actually the reason people experience vection in VR is not focal depth but the dissonance between what their eyes are telling them and what their inner ear and tactile senses are telling them.
It's possible they get headaches from the focal length issues but that's different.
Pure functional programming and lazy evaluation.. sure, you could create classes and a meta-function that selectively eval's thunks at a time, but the call site of that kind of library would look atrocious..
You might be able to hack on some of the datatype semantics into JS prototype-based inheritance (I'd rather start with TypeScript at that point, but then we're back at the "why isn't it a library" debate) to keep those ontologies from being semantically separate, but that's an uphill battle with some of JS's implicit value conversions.
I consider Logic Programming languages to be the go-to counterargument to TFA but yeah, anything with lazy eval and a mature type system are strong counterexamples too.
Almost made it into 1.18 but looks like it doesn't add enough value and has some open questions like what to use for a backing data type and what complexity promises to make.
It's not a yes/no per contestent, it's per edge between contestants. There are n(n-1)/2 of these.
A true answer for a potential match is actually a state update for all of the (n-1) edges connecting either contestant, that's 2(n-2) edges that can be updated to be false. Some of these may already be known from previous rounds' matchups but that's still more than a single binary.
I think that LLMs will be complemented best with a declarative language, as inserting new conditions/effects in them can be done without modifying much (if any!) of the existing code. Especially if the declarative language is a logic and/or constraint-based language.
We're still in early days with LLMs! I don't think we're anywhere near the global optimum yet.
You can go one step further than that and calculate a fairness measure using something like the Gini coefficient (*) and analyze how much it has changed over time.
The source is electrical noise, but the solution of isolating the audio chain from the computer's USB means that in the future you might not notice when you've introduced another GPU memory bandwidth hog into your rendering loop.
Is it ironic that they publish it as a PDF? I get that it's the easiest way to control the print layout and also nicely self-contained... but how many of us are opening it in a sandbox as we should?
And python didn't get it right the first time either. It wasn't until python 2.3 when method resolution order was decided by C3 linearization that the inheritance in python became sane.
It really was way ahead of its time. I remember the handwriting recognition being excellent for the time, too. Meanwhile Palm forced its users to write each letter one at a time in a tiny box and requiring specific sequencing of each stroke too.
Newton had a modem module you could plug in and third parties had written web browsers for it, it basically was the first smart phone just without the phone.
Trying to imagine that level of innovation, but starting from present day tech, is very interesting.