Quantum 'pooters
While vast swaths of the financial and software engineering management
words are broiled by cartoon-fight-cloud levels of mania over Large
Language Models (which are now, annoyingly and universally, referred to as
"Artificial Intelligence" because we haven't learned our lessons vis-à-vis
the relationship between hype and reality — having a foundational trust
and pastoral elevation of the door-to-door salesman here in these States
United — and even permit the constant carrot-dangling of some promise of
Anyways… quantum computers are one such thing. More generally, our advancing ability to observe (pun) and manipulate things that don't follow the physical properties we're used to observing. These advancements in quantum stuff unlock novel functionality that we can build on, things that didn't exist before and fundamentally couldn't be done accurately or in a reasonable amount of time. The short list of stuff I'm most excited about:
-
Laser cooling maintaining accurate position measurements over time with no outside connections very practical real-world applications - What are being referred to as "cryptographically-relevant quantum computers", which, in practical terms, means quantum computers with enough memory and processing speed to do on-the-fly memory correction. This is necessary for carrying out larger and slower operations, as memory is only stable for a short period of time before being observed by the heat'n'motion of the universe.
I ramble, but the distinction I'm trying to draw is between
doing old things faster and
doing new things. We've been throwing a lot of
time, energy, and media coverage on the former, and very little on the
latter. This may be as simple as: it's easier to get clicks from
theFamiliar++ and harder to introduce and sell a topic that
introduces a new atomic function to our technology.
This makes me think about the introduction of novel atomic functionality in programming languages — something that:
- didn't exist before, and,
- whose behaviour would be impossible to reproduce within the language before its introduction.
In the ECMAScript specification, many new language features are
distillations of things that people had already written — functionality
provided by popular code libraries which was universal-enough in its
applicability to justify its inclusion in JavaScript-proper. However,
other functionalities are introduced which expose something that
couldn't have been reproduced accurately in earlier versions of
the language not including that feature. One such example is the
introduction of the
WeakMapWeakRef
Without the fundamental support of weak references in a language, these patterns are impossible to reproduce naturally, and require some central register/unregister API, implying more boilerplate code and (often) more opportunities for memory leaks.
From my experience, the introduction of these fundamentally new behaviours
are (similarly) much less talked-about than those distillations of
already-possible functionality; or, at least, as-talked-about — hitting
something like a