This RFC (the concept behind it) has been in the works in one form or another since 2008
> The HTTP SEARCH method was first formally proposed in November 2008 within RFC 5323.
> Before it became a full RFC, the proposal progressed through the IETF under the working group draft name draft-ietf-httpbis-safe-method-w-body. Its formal journey began in March 2021 as an adaptation of the older SEARCH method (from WebDAV's RFC 5323), before being renamed explicitly to QUERY in later draft revisions.
There's no "pretending" this is a good idea, a ton of very smart people have spent a tremendous amount of effort refining this solution. It's incredibly well thought out.
I find it really fascinating that you use the metaphor to GA of a senior dev sweeping all the cruft away into a single clean abstraction, is that my read/smell of TFA (as a layperson for this depth of math) is that GA runs the exact same risk of leaky abstraction. It's really general and elegant and covers all these cases with a single abstraction, but in doing so it sometimes conflates very similar things (precisely because they are so similar) when they really ought to be separate things. Like a complex number and the rotation operator it performs. My seat-of-pants take is GA is just a bit too DRY.
My understanding is too shallow to get why we don't just go straight for EA/Clifford Algebra when the "lower" systems like cross product are insufficient.
I share the author's intuition that there ought to exist some mathematical object that begets Clifford Algebras and multivectors and GA and all the like that we have yet to discover.
> They're spending their precious time on this Earth learning a dead language instead of learning about the law or bugs
I know this is hyperbole, but it's my opinion Latin/Greek emerged so dominantly in law/bio/medical fields is that it allows at the same time semantic bleaching and composition. "Jargon is a DSL" if you will. Sure, you could say "heart muscle no worky cause insufficient oxygen" but "myocardial infarction" is a) more concise b) comprises reusable composable pieces of meaning (myo + card + -ial, in + farcire + -ion) c) most importantly, is extremely precise. It's like the trouble of using English + LLM to define a program, vs just writing damn code. Sure you can do the former, but it's lossy, and that lossiness causes issues.
Did you mean hyperthermia? This whole thread sent me down a rabbit hole (I have several close folks afflicted by Lyme) and while at first glance hyperthermia might seem woo-ish, there is real research being done, particularly on hyperthermia + antibiotics. The chief drawbacks are cost (I'm seeing $30k and up and not usually covered) and strain on the body. Friedrich Douwes pioneered much of this.
Douwes F. Komplextherapie der chronischen Borreliose (Lyme disease) - Ein neuer Therapieansatz: die Antibiotika augmentierte Thermoeradikation (AAT). OM & Ernährung. 2018;164:F10.
Douwes F. The successful antibiotic augmented thermal eradication of chronic lyme disease. Paper presented at the 32nd ESHO Meeting, Berlin, 16–19 May 2018.
Robot arms can have reproducible movement with error bars measured in double-digit microns. Where they lack is in the force feedback, and even then they have had huge strides.
It also directs Github to automatically collapse those files to the "Show Diff" interface by default. I'd still call the contents of things like lockfiles, protobuf output, big JSON blobs, etc, "noise" when reviewing PRs for code changes, but that doesnt mean I dont look at them.
Super fun, got 70,250. Friends have always lightly ribbed me for having to go home and look up words i've used. Those remaining 100k words must be really obscure.
One suggestion would be more convincing decoy choices, some were pretty silly. But I have no idea how they come up with them.
That sure is an interesting take from someone with "anarchist" in their username. IMHO corruption is any time you use power/influence/station in order to skew the normal well-behaved channels of governance (cybernetics) for personal gain. Any system with hierarchy can have corruption. Bernie Madoff was an example of illegal, private industry corruption.
Psychededics are unpredictable. We know the government looked into their use as thought- and behavior-manipulating tools (MKUltra) but the results proved too chaotic. You might get a manchurian candidate...or the unabomber. But most likely just a renewed outlook on life.
Psyches basically raise the "temperature" (in machine learning parlance) of the brain, increasing crosstalk. This can jostle folks out of a mental rut. But it can also create positive feedback loops of upheaval.
Soma would only work as it did in BNW if society controlled essentially all sources of information - which is essentially the whole premise.
Drifting? I think it's there. basedpyright is awesome and super fast. Our latest services are all CI gated by type checking. Early in my career you'd hit so many dumb errors running your code - NoneType, attribute, value, and type errors. I'd say that's been cut over 95%.
According to Pew, almost 70% of teens report to have used LLMs/chatbots, and 30% use it daily. This is also over 6 months out of date, which feels like an eternity at the current rate things change.
> > As a group, teenagers and young adults hate AI
Anecdotally, I've observed a robust correlation between the cost/quality of the model, and attitude towards it.
Most of the general public, young folks, and old folks (ie outside gen z, millennials, and some X) are using free models, usually what's immediately available (cough copilot cough), have really unreliable results, hear all the hype, experience dissonance, and chalk it up to just hype, and walk away thinking AI is a crock of junk.
The Z/Y/G cohort - the ones that grew up alongside the growth of the internet - seem to be the best adopters. They recognize a system which is powerful, albeit flaky, and know how to extract utility from it without over-reliance. Especially ones with paid flat-rate subscriptions.
The power users - the ones using API/paid (by usage) models, tricking out their claude with plugins, seem to have the least amount of hate, but rather a healthy respect for a powerful disruptor.
I also don't buy the whole "the young'ns have never dealt with barriers of entry to the internet and thus lack the tech skills the millennials developed." I think the internet cohort that adopted tech was always split between the powerusers/curious learners, and the "just get my goal accomplished and get out" folks. I think that's roughly the same percentage of folks in Z/alpha, and these kids are just as savvy and aware of limitations of the tech.
I think the analysis-space really needs to be divided into three groups: software, media (audio/video/image) generation/alteration, and everything else.
Software - this tech is ludicrously powerful and productive. But it's a force multiplier, not a "push button, receive software" system. Great devs that know how to wield it will become überdevs, becoming more productive and with lower defect rate (we have objective internal numbers backing this). But bad devs and non-devs will become high output slop factories. You basically need a dedicated platform team to keep things on the rails. I think this is very akin to the internet bubble. The process, institutional knowledge, and feedback systems developed at this time will grant the "survivors" massive edges after the pop.
I think media generation is or will be a solved problem. Animators, 3dfx, background/filler music composers, those jobs are in sorry shape based on current trends. But a cost explosion could easily level the playing field.
Everything else, where middle managers are aggressively pushing AI usage? Yeah maybe. At this time, other than for document retrieval (basically suped-up search), the "productivity" gains don't really map to value gains. Oh wow you can crank out powerpoint slide decks 50% faster. Write 50% more corporate emails employees barely read anyways. There's definitely a trust issue there with hallucinations. If the reliability gap can be solved (the bots don't even have to be correct, they just need to be less confidently incorrect, and I already see this somewhat with my own agents with tuning), then that could prove the turning point between "begrudging usage at the behest of higher ups" and "actual productivity enhancer."
Does no one remember in the dot com boom all the internet skepticism? "I don't trust it with high value orders, what if it crashes or loses data? Call me old-fashioned but I'd rather write it down." That attitude was quite prevalent for years, even into the 2000s.
Are the datacenters that are being built not directly analogous? Even if the hardware in them is cooked after 5 years, the buildings, power, cooling, and fiber interconnects are still all valuable.
The models may go out of date but the process and software are continuously improving.
The younger devs have largely been the ones showing us old farts (eg millennials) how do to the really sophisticated stuff with claude - custom skills, plugins, tooling like openspec, things that have had massive benefits over stock claude.
We are nowhere near the ceiling in terms of process either.
Re: flat rate going to by-usage, I believe this is largely a long tail problem. You have a small number of power users that capitalize on the flat rate to use the service orders of magnitude more than the average user.
I think my company is a microcosm of the current state. The non-engineering side (HR, correspondence, marketing) are on the "forced adoption" side, giving out gift cards to folks using Glean the most.
In engineering, we can't raise token budgets fast enough. Devs are "routing around damage" when they hit caps, going from claude to opencode to copilot. Productivity is up (roughly) 100-300% in terms of story points and 75-200% in lines of code. And defect rate is down [0], more bugs are caught in review before QA or prod. Our teams are just starting to figure out our new workflows too, for design -> spec -> code -> review, it'll only get better as we refine the process.
It's looking like software industries will reap massive benefits, while most others which have some error tolerance will only see modest gains. It's unclear how it will impact high accuracy fields like legal (it might even be net negative).
Also which is it - a useless technology that has to be force-fed because it sucks, or a economy-shaking game changer that will put folks out of jobs en masse? Those seem like a contradiction.
0 - i think process here is extremely important. I think it would be very easy to create an unmaintainable slopocaplypse. We have an informal platform team of about three (including myself) that have been affectionately and informally dubbed the Tech Priests of Mechanicus Adeptus (warhammer reference) that ensure the prompts/skills and associated tooling are optimal, that code standards are enforced, and that solutions are converging at the system-wide level.
That's literally what OpenSpec does (https://openspec.dev/). It's quite nice. I've only exceptionally rarely seen claude do something wrong based on spec docs when it's fully spec'd out. More often it's because something wasn't nailed down and claude was forced to make assumptions.
The downside is the ospx markdown specs sometimes end up too granular, focusing on the wrong or less important details, so reading the specs feels like a slog.
Also at times aspects of the english language spec end up way more verbose than just giving a code example would be.
> The HTTP SEARCH method was first formally proposed in November 2008 within RFC 5323.
> Before it became a full RFC, the proposal progressed through the IETF under the working group draft name draft-ietf-httpbis-safe-method-w-body. Its formal journey began in March 2021 as an adaptation of the older SEARCH method (from WebDAV's RFC 5323), before being renamed explicitly to QUERY in later draft revisions.
There's no "pretending" this is a good idea, a ton of very smart people have spent a tremendous amount of effort refining this solution. It's incredibly well thought out.