Aside: I feel like this could be another intro example for students on how exponentials are a limit of a sequence of polynomials. We usually first see this in compound interest [1]. But I remember having a similar ah-ha moment when I first saw matrix exponentiation.

[1]: https://en.wikipedia.org/wiki/Compound_interest#/media/File:...

It does offer a deep dive into what reactors are but why would I bother to learn? If OP reads my comment, that's what I would add to this landing page. Show me why the alternatives mentioned are inferior.

> One setting drives this,...

> The cost is now about the rows you actually touch, not rounds times table size.

Etc.

I get the brain scramblies [1] from trying to parse this writing style at work so I hate to see it elsewhere. Apologies if I'm wrong. But if I'm not then OP don't use an LLM to write for you. It's hazardous to your reader's health [2].

[1]: https://www.youtube.com/watch?v=ipUJq-odt5Q

[2]: https://discourse.haskell.org/t/how-to-keep-enjoying-program...

I'm open to the dualist's position on consciousness if that's what you're really asking. Though that's more because I find the physicalist's position so untenable [1] that I'm forced to consider alternatives.

[1]: https://plato.stanford.edu/entries/physicalism/#NumbAbst

2. "of sufficient complexity" is doing a lot of work here. Read Ted Chiang's article. I agree with him: there's nothing that prevents software from being conscious in principle. But there is also no reason to suspect that LLMs in particular are conscious based on very reasonable assumptions about what that would look like.

> Slop UI is the UI that AI cooks up that looks off, where it’s not supposed to be, doesn’t serve a purpose or when a UI is too generic.

> This is seen in vibe-coded UI without a vision. Vibe-coded UI can look great when done right, but most don’t. And it makes the apps look cheap and unappealing to use.

Those are paragraphs 3 and 4.

There's a great article by author Ted Chiang discussing this in depth [1].

[1]: https://www.theatlantic.com/philosophy/2026/06/no-artificial...

https://www.scattered-thoughts.net/writing/against-sql

That particular post ends with a wish-list of items so it's the most similar to the OP. But there are others on the site that I quite enjoy (click on the home icon and search "SQL" on the page).

My personal take is that SQL will continue to reign for a long time because of the how monumental the task of replacing it is due to the inherent complexity of databases. LLMs make this worse because they're really good at translating prose to SQL. Now that it matters less how annoying SQL is to programmers, SQL will become more like assembly over time: something mostly computers write because it's complicated for humans to deal with directly. This is deeply ironic given that SQL was ostensibly designed to read like prose, i.e. to be easy for humans.

I'd love to evidence what I'm saying with specific numbers since this kind of discussion would benefit from being as objective as possible. Sadly I don't have them. But I still believe what I'm saying and I have a few guesses about some of the causes:

1. Immutable data - so, so many bugs are caused by data mutating out from under you in subtle ways. If you write `x = 1` in your Elixir function, nothing can change the value of `x` except an explicit rebinding. You can then write e.g. `y = f(x)` and know `x` remains unchanged after. Note: this is also true even if the variable is a composite type. `my_struct = blah()` will remain the same in it's entirety no matter what you do with `my_struct`. This is different than in JS where e.g. you can change the contents of an object even if it's declared `const`.

2. Assertive style - the Elixir community favors writing things in an "assertive" fashion [1]. Briefly, this a way of writing code that will fail the moment an assumption is broken rather than letting the issue propagate.

3. Pattern matching (somewhat like destructuring in JS) - Elixir code actually ends up feeling "typed" with pattern matching. E.g. `%Time{} = today = Date.utc_today()` will attempt to bind `today` to the result of `Date.utc_today()` and will raise a `MatchError` when the result, a `%Date{}` struct, fails to be a `%Time{}` struct. Or `[a, b] = [1, 2, 3]` will raise a `MatchError` because `[1, 2, 3]` isn't a list of length exactly 2. You can use pattern matching to write very assertive code quite tersely.

These reasons are all local properties of code. But when all its parts are written in this way, a program as a whole gains a level of correctness that's hard to achieve in a dynamically typed language without them.

Also these reasons aren't exhaustive, but they're top of mind when thinking about this topic.

[1]: https://dashbit.co/blog/writing-assertive-code-with-elixir

It's the same with tough on crime. "What, you want criminals to keep getting away with it?!"

> The primary trade-off observed is the increased calculation time for OLS and SVD steps. Consequently, the next phase of this work involves implementing these operations within custom Triton kernels to amortize latency. By viewing the cache through the lens of reconstruction fidelity rather than just memory capacity, we can develop more sustainable architectures for long-context inference.

Reading between the lines, the increase in latency was so significant that they didn't want to include it before they had a chance to try and optimize the problem away first.

Still interesting research. Hope they get good results!

Your reasoning relies on this being true:

> [CRQCs] will be slow, expensive, and power hungry for at least a decade

How could you know that? What if it was 5 years? 1 year? 6 months?

I predict there will be an insane global pivot once Q-day arrives. No nation wants to invest billions in science fiction. Every nation wants to invest billions in a practical reality of being able to read everyone's secrets.