kevindamm

It doesn't have to imply replacement. Do you stop thinking just because other humans can?

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.

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.

ELI5: explain like I'm five,

ELIF: explain like I'm forty.

key chain furby lootboxes

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.

Would a high enough dose of UV also work? I suppose it would ruin most pigmentation too, though.

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.

https://github.com/golang/go/discussions/47331

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.

Broccoli Man! classic

https://youtu.be/3t6L-FlfeaI (2010)

To be fair, a lot of this changed after that video became a meme.. but I'd bet that the broccoli man template is still trending on memegen

Have we abandoned the term "generate" already?

and you could shim these gaps with custom components, hypothetically

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://wikipedia.org/wiki/Gini_coefficient

replace the scope with a dimmable light and we might have a better solution than low-decibel audio hum

or perhaps live wire into the seat, tied into a transistor on this signal, so if performance drops enough you're sure to be alerted to it

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.

Good story, though.

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.

http://mail.python.org/pipermail/python-dev/2002-October/029...

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.

I still have my Newton but I wasn't, nor am I, elite.

I didn't store recipes on it, though.

We're told not to feed the wildlife at parks and beaches because of the dangers when they become dependent on visitors for their food source. It changes their natural behavior to the extent that it becomes difficult to revert to natural food sources in the absence of visitors.

(there are other behavioral and disease-related dangers but they're not as appropriate to this metaphor)

I think the more alarmed voices in this comment thread are not reacting to the change or "exponential progress" but are instead concerned about the impact of becoming reliant on something else to do our remembering.

This last part is anecdata (but no worse than the survey data in TFA), I think smartphone users have not really lost the ability to memorize, in general, but that the things being memorized are different. If the memory test (mentioned in a cousin-comment) had a set of 20 memes instead of 20 words, I expect most study participants would be a lot better at recall.

I suppose the question of "is this like junk food, though?" may be relevant.

which is a real problem if a significant part of being in the population of whale or addict involves AI psychosis

This was, I think, the greatest strength of MapReduce. If you could write a basic program you could understand the map, combine, shuffle and reduce operations. MR and Hadoop etc. would take care of recovering from operational failures like disk or network outages by idempotencies in the workings behind the scenes, and programmers could focus on how data was being transformed, joined, serialized, etc.

To your point, we also didn't need a new language to adopt this paradigm. A library and a running system were enough (though, semantically, it did offer unique language-like characteristics).

Sure, it's a bit antiquated now that we have more sophisticated iterations for the subdomains it was most commonly used for, but it hit a kind of sweet spot between parallelism utility and complexity of knowledge or reasoning required of its users.

If you count with each finger as a binary digit you can count up to 15 on one hand!

255 if you use both hands!

More like 1023 if you also use thumbs but I prefer to use them as carry, overflow bits.

It's never too late to learn queueing theory

...because the typical setup assumes λ ≤ μ so all arriving jobs eventually get serviced.

I think there's a lot of unmet potential in design of interfaces for pipelines and services that really gets at the higher level you mention. There are some universal laws, and some differences between practice and theory.

I remember the 3D glasses that you could plug into the Sega Master System in the mid-80s. They took what would be interlaced frames and rendered them to different eyes instead (which made the version getting shown on the connected TV pretty trippy too).

And then there was the time travel arcade game (also by Sega) that used a kind of Pepper's Ghost effect to give the appearance of 3D without glasses. That was in the early 90s.

I think the idea of 3D displays keeps resurfacing because there's always a chance that the tech has caught up to people's dreams, and VR displays sure have brought the latency down a lot but even the lightest headsets are still pretty uncomfortable after extended use. Maybe in another few generations... but it will still feel limiting until we have holodeck-style environments IMO.

Something I haven't seen mentioned in this thread or TFA is just how high corporate taxes were (and even personal investment taxes) in the 50s and 60s, and this influenced spending on R&D immensely because that investment wasn't considered taxable income. Tax rates were over 50% for much of the era of Bell Labs and Xerox PARC.

The first time I learned it was from a book by LaMothe in the 90s and it starts with your demonstration of 3D matrix transforms, then goes "ha! gimbal lock" then shows 4D transforms and the extension to projection transforms, and from there you just have an abstraction of your world coordinate transform and your camera transform(s) and most everything else becomes vectors. I think it's probably the best way to teach it, with some 2D work leading into it as you suggest. It also sets up well for how most modern game dev platforms deal with coordinates.