scythmic_waves
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.
I don't disagree with your comment exactly. But I primarily wanted to push back on a common response to scientific works. Something to the effect of "Well obviously, everyone knew that!".
Except they didn't because they (presumably) didn't actually investigate. And even after the science, they still don't _know it_ know it. But post-scientific inquiry, they have a much stronger claim to the knowledge than they did before. So the type of dismissal in the root comment is seriously missing the point.
https://en.wikipedia.org/wiki/Whey_protein#Microbial_product...
It's not theoretical either. You can buy vegan dairy products made from this method today.
https://www.youtube.com/watch?v=dO6ApZlxqo8
Sidenote: is that Clancy Brown doing the voice over on the 'Home' commercial?
I have the technical background to write Latex and Typst documents but I honestly didn't want the headache. Plus I'm the type to futz with styling all day long instead of putting down actual content. RenderCV was simple to use and did exactly what I wanted.
I have the power to do it. Why would I not?
As a PR reviewer I frequently pull down the code and run it. Especially if I'm suggesting changes because I want to make sure my suggestion is correct.
Do other PR reviewers not do this?
Though I think it's more of a hobby language. The last commit was > 1 year ago.
The 2nd link seems reasonable to me? Why does a study about 25k workers in Denmark (11 occupations, 7k workplaces) not count as evidence? If there was a strong effect to be found globally, it seems likely to be found in Denmark too.
Also, what about the other links? The discussions about the strange accounting and lack of profitability seem like evidence as well.
If anything, this article struck me as well-evidenced.