I get that's what you're suggesting. The locking per-axis or across all axes is fine but doesn't address the problem I'm talking about. In gimbal lock, which many graphics programmers first encounter by using only sequential rotations around the camera's axes, you can get into an orientation where you lose one of the three degrees of freedom.
I think they're referring to the Enterprise sales where people have felt pressured to sign six- or seven- figure contracts after usage goes above a certain point. However, all the articles I've read on it are from companies using Cloudflare to do suspicious things with rotating domains through IP addresses, or doing things to try and get around service costs. It also seems like they give you months of warning and will try to convince you to sign up for Enterprise, they don't just shut things off. But their sales team seems to portray themselves as legal, support, or compliance teams sometimes so not exactly forthcoming in their approach either.
I'm a happy user of Cloudflare, but if you're using it for domain registration and hosting infrastructure, you need to see it as a single point of failure. Any account issues and you won't be able to point your domain to an alternate host while you work things out. Any service outage in CF systems will similarly lock you out of routing around the failure. It's better to have DNS off of cloudflare if they're handling your hosting services also. Or host elsewhere and only handle domains on cloudflare. Their domain pricing doesn't add any costs over the base registrar cost, so the latter is a reasonable option.
If you're suggesting that the different columns of a comptometer would relate to different rotational axes of the ball, you will likely run into gimbal lock in 3D.
You could build an interface in 4D around quaternions but that is much more complicated than my suggestion (even including the part where you learn morse code).
The quoted part of my comment is in reference to the core topic of TFA where iOS and Nothing/Android photo apps handle the "pressed again during rotation" action differently. That "rotate the typewriter ball" interface runs against the same problem, by necessity of rotating a physical ball.
There's nuance, for sure, I think that's why ancestor comment added gestures generally...
For your earlier example, in the scope of working math problems from Wikipedia, that is probably one of the worst examples. Anyone going down a math rabbit hole while on Wikipedia quickly gets frustrated by how every topic page starts with the most generalized form. This has intrinsic value by being more referentially transparent but offers very little use to someone trying to grasp the core concept from its more case-specific (and simpler) representations. Compared to something like math.stackexchange it offers no easy way to construct exercises to work on paper, and especially when compared to a Math textbook that has a good progression of exercises, and half of them with solutions.
Reading prose is also two different worlds, for me. I learn new vocabulary much more often when reading a novel than when reading the equivalent volume of text on a social news site. It also holds my attention on a single topic for longer. This goes for both fiction and non-fiction, in my opinion.
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.
https://en.wikipedia.org/wiki/Gimbal_lock