466 karma · joined March 20, 2020
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.
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.
E.g. the debugging question: I use all of those methods to some degree. But I "think logically about the code" (or whatever that choice was) nearly 100% of the time, so I felt compelled to pick that one even though I didn't feel like it represented me all that well.
They're selling a meat replacement. Replacing the meat in my diet with their product does not work for my goals without additional planning to compensate. Therefore it's not a good replacement for me. A criticism need not apply in all cases to be valid.
> I'd still be able to hit 150g/day at least without really trying.
What are your calorie goals? If you're in a surplus, maybe. But I'm currently in a deficit with 150g protein / 1600 calorie. I do not find that I can hit this goal "without really trying", _especially_ without protein powder.
And to clarify, it's 100% possible to hit my goals eating vegetarian/vegan. But with meat in my diet it's much easier because their high protein content gives me more flexibility with the rest of the diet. If I wanted to do it vegetarian, I wouldn't use beyond meat because it'd be even harder than other options.
As someone doing weightlifting, this is the primary reason I don't bother with vegetarian meats. They actually taste pretty good IMO, but they don't offer nutritional benefits commensurate with animal meat.
It's a shame, really. I'd gladly incorporate them if I could get a similar protein : calorie ratio.
I'm much more interested in how much the average student has had a phone to distract them during their lifetime. For the incoming 2025 class of 18 year olds, the iPhone came out the year they were born. So potentially 100%. I expect that plus the availability of LLMs is a deadly combo on an engaged student body.
What weird ideologies?
However I still sympathize with the parent comment. The niche-industry-exception state of affairs will become less true over time. And then you're left with the same set of incentives (minus dedicated hobbyists).