HNHacker News
TopNewBestAskShowJobs

antics

4,248 karma · joined August 13, 2010

clemmer.alexander@gmail.com alex@moment.dev
submissionscomments
antics··on Is 'Attention' the Essence of Intelligence?
No. It definitely has resulted in practical improvements to attention. One practical improvement is that kernel smoothing is vastly easier to explain than "attention", which I think I have already demonstrated here.

Aside from that, kernel smoothing has roughly 70 years of literature devoted to every practical aspect you could imagine: approximation, accuracy, pedagogy, behavior under sparsity, relationship to other well-known theories like Bayeisan learning, and so on. Variants like Performer and elliptical attention, all directly arose from the knowledge that attention is intro-grad-stats kernel smoothing. A large portion of our understanding of ICL is directly or indirectly resultant from the fact of this correspondence.

antics··on Is 'Attention' the Essence of Intelligence?
It's hard to speak for every language on Earth, but generally languages that have less flexible word orderings will have correspondingly more complicated morphology. In those cases, order does obviously still matter, but instead of in word orderings, it would be in things like prefixes and suffixes.

There isn't really a way to get around this. Natural language IS structured as a recursive tree. Our job is to extract this tree from a flat stream of tokens (or similar), and straightforwardly the only way to do that is to make the ordering of the tokens meaningful. There is no other option! This is how 100% of parsing works in any context whatsoever, both theoretically and practically.

antics··on Is 'Attention' the Essence of Intelligence?
And with this reply we begin one of the permanent debates on this subject. Regardless of where anyone here comes down on this particular case, "it" is an indisputable truth that not all English sentences have subjects. Yet, many of them have pronouns where a subject should be. Maybe the famous example isn't one of them, but "it" is not at all hard to come up with a sentence where that is true. :)
antics··on Is 'Attention' the Essence of Intelligence?
French is interesting because it evolved this so-called "dummy subject" pattern (which is actually called "subject-prominence") for an entirely different reason than English.

French is descended from Latin, which is "pro-drop" in the sense that you'd drop the "dummy subject" and simply write "pluit." Later, Old French, like English, lost most of its cases. Because of that, many word endings started sounding very similar (a problem known as "agreement syncretization"). The pro-drop "null" subject disappears in the record roughly as that happens, presumably to help disambiguate.

This is an entirely different path than English took, and it's also not a path any other Romance language took. Spanish isn't even subject-prominent. It fully allows the "null" construction, e.g., "llueve", which literally is just "rains."

antics··on Is 'Attention' the Essence of Intelligence?
You could be right, I have not kept up with the literature very closely! I'm just trying to help people understand that this article does not capture something very important about the Vaswani et al formulation of the transformer architecture. :)
antics··on Is 'Attention' the Essence of Intelligence?
The authors did not know that it was Nadaraya-Watson kernel smoothing when they wrote the paper. Not recognizing that the novel thing you are doing is secretly another, very old, very common thing, turns out to be an extremely common ailment in modern ML/AI literature. :) I suspect this is true also of physics.
antics··on Is 'Attention' the Essence of Intelligence?
kNN imputation is a special case of kernel smoothing: one where the "kernel function" (which prescribes weights to the points) is uniform.
antics··on Is 'Attention' the Essence of Intelligence?
For those who are not math people, this comment is referring to the fact that "attention" is formally equivalent[1] to Nadaraya-Watson kernel smoothing, which is a kind of weighted average. Yes! Incredibly, attention is just a weighted average.

Imagine you have a series of (x,y) coordinates. You receive a new x coordinate, and you'd like to predict the corresponding y. So, the absolute dumbest thing you can do is find the nearest x, and then report its corresponding y as your prediction. The second dumbest thing you can do is find the n closest x coordinates, and then average their y values together, and output that as your predicted value. And the third-dumbest thing you can do is that n-closest-average thing, but give the "closest" x coordinates the most "weight" when you average them. (Technically, not always "closest": you have some "kernel" function which does the weighting, but "closeness" is a good kernel so I will use it here.)

That third-dumbest thing is Nadaraya-Watson kernel smoothing. And that's what attention does. You have a big list of vectors. You compute a weighted average of those vectors. You now have a new vector. You can do what you want with it, but LLMs will generally turn that into a distribution over token types, from which you'll generally want to select either the top one, or weighted-randomly one from the top k (known as "increasing the temperature").

With all that said, I'm not sure "Kernel smoothing is all you need" is actually materially better than "attention is all you need" for 99.999% of humans. :)

[1]: https://arxiv.org/abs/1908.11775

antics··on Is 'Attention' the Essence of Intelligence?
Yes, as I mentioned to another commenter, I'm talking about the original formulation because that's what the article talks about. We have more options now, although (as you seem to be suggesting) they do all necessarily model position. They have to—there is no other way to do things like recover the subject in an English sentence without positional information.
antics··on Is 'Attention' the Essence of Intelligence?
To clarify, I'm talking about the original formulation of the problem, where positional encodings are crucial, because the article is talking about the original formulation of the problem.

But these days, there are many more options. They all maintain this positional information in one way or another. The one you cite (as I understand it) drops the positional encodings after pretraining, and keeps (e.g.) the causal mask.

antics··on Is 'Attention' the Essence of Intelligence?
As an NLP person it's very hard for me to endorse this explanation, because the Vaswani et al transformer (as it is described here) simply does not work until you add the most important ingredient of all: the positional encoding.

Most of the semantics of a sentence are indicated by the precise order the tokens appear. This is easiest to see in a language like English, since it is visible in two very prominent ways.

First, the morphology is fairly derivational, meaning you can keep adding suffixes to things and English speakers will generally get what you mean. For example, add some more suffixes to that word: derivational-ish-ly. You've probably never heard this specific variant, but you still probably have some idea of what it means anyway. The transformer can only capture these semantics if it has some representation of the fact that the suffixes inflect the meaning of the word's root (presumably something like `deriv`). English encodes this entirely by the position of the suffixes relative to the root. Without the positional information, there is no way to recover it, and sentences would lose much of their meaning, since English depends heavily on this construction.

Second, English has relatively few cases, and thus relies very heavily on the order of words to indicate what is the subject and what is the object. English specifically is Subject-Verb-Object, and the instinct of native English speakers to use SVO ordering is so strong, you will find them inserting nouns and pronouns into sentences that do not actually have subjects at all. "It's raining outside" is the most famous example. This sentence has no subject at all, and yet native English speakers feel a strong need to place "it's" at the beginning.

If the transformer did not have positional encodings it would be completely hopeless to recover what is the subject and what is the object from English sentences. There simply is no other way to reliably tell, other than inspecting the word positions.

It's worth noting we also do have the counterfactual. Generative language models that explicitly exclude positional information, like Latent Dirichlet Allocation, are only able to (essentially) cluster word co-occurrences. That is not as useless as it sounds—if I say "fire house burning ambulence" you kind of get the point even without a subject or an object—but it certainly does not generate the lucid, provoking sentences that modern LLMs do.

antics··on I think we might lose public key cryptography
Just to be absolutely clear, the giant OpenAI math dump replaces two (2) already efficient probabilistic algorithms with deterministic ones. Neither affects encryption as it is deployed today (one is a quantum algorithm, and the other is factorization over prime fields).

I think it's fair to say that in the last month we have learned 0 things that would specifically confirm or disconfirm this stated view, either directly or indirectly. And that is not really Matthew's concern, anyway. His actual concern is that computers are really good at math, and if we point them at something like Module LWE or ECDLP there is a real chance that it (essentially magically) breaks them. See his statement at [1].

For better and for worse I think we are in a crisis of empiricism. As a community we are worried enough about the outcomes of breaking something like encryption that we're willing to admit statements like this one, even though we have no real, actual, concrete evidence that would indicate whether they're true or not. The line of thought Matthew articulates here (i.e., we can solve millennium problems thus "optimism [related to encryption] is a very opinionated bet") may be defensible from a risk management perspective, but it is absolutely not defensible as a statement of knowledge. Internally that's fine, but the public (including the technical public) is not going to make that distinction. They will interpret it as knowledge. That does not help us.

[1]: https://x.com/matthew_d_green/status/2108281944291393983

antics··on Olo (Color)
If you are interested in "imaginary" colors, the gamut is actually well-specified, and (I hope it is appropriate to comment) that I made a visualization where you can drag a selection thumb over the gamut to see the "simulated" version of that color. Also include it is a 12-step contrast-sensitive color palette generator for said imaginary colors, which would allow you to make websites and (say) vscode themes using entirely imaginary colors! https://docs.moment.dev/d/hausdorff/2zmqjlmldchela29xvbzlbki...
antics··on Incident March 30th, 2026 – Accidental CDN Caching
So on the one hand you have a direct statement from the source that the cause of this incident is humans. On the other hand, while we all agree there is no specific evidence that AI caused the issue, the guy who made that statement, like, really loves AI.

In my life I have gone back and forth on the idea that 12 angry men is a kind of facile representation of how people think and what kinds of evidence really form the basis of a reasonable society. This comment section is doing a really good job of stretching my resolve to believe we are getting at least better.

antics··on Incident March 30th, 2026 – Accidental CDN Caching
> I'm not sure why people are so quick to discount [AI] as a potential source of the issue.

Because (per the link above) the CEO said that (1) it was their fault, and (2) it had nothing to do with AI.

I understand that on this forum statements like this are inevitably greeted with some amount of skepticism, but right now I'm seeing no particular reason to disbelieve Jake, and the reason that "if they did use AI they'd deny it" should frankly not be considered good enough to fly around here. Like probably everyone in this comment section I'm open to evidence that they used AI to slop-incident themselves, but until we can reach that standard let's please calm down and focus on what we actually know to be true.

antics··on Incident March 30th, 2026 – Accidental CDN Caching
The CEO says it's not: https://x.com/JustJake/status/2038799619640250864

A lot of people are confident in enough in their ability to spot AI infra that they are willing to dismiss a firsthand source on this, and I admit I have no idea why. There isn't any upside to making this claim, and anyway, I assure you that people need no help at all from AI to make these kinds of mistakes.

antics··on Return of the Obra Dinn: spherical mapped dithering for a 1bpp first-person game
> It feels a little weird to put 100 hours into something that won't be noticed by its absence. Exactly no one will think, "man this dithering is stable as shit. total magic going on here." I don't want to give people problems they didn't know they should have though so it was worth fixing.

I mean maybe it's just me, but that is literally the first thing I noticed and I appreciated it so much I instantly bought the game. I don't even play video games much!

antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
lol ok we can talk and record it. I want to make it clear that this is NOT a debate, though. I actually want to be convinced!
antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
But Kevin, prosemirror-collab does give me offline editing. I use it literally every day, entirely without issue. I write offline on different devices, and whenever I come online, it all syncs up. No issues.

It does not give me p2p topology. Is that what you mean?

antics··on We're building a better rich text editing toolkit
I run a VC-funded startup. We fund the extremely high-quality OSS `react-prosemirror` project at > $10k a year. I really, really think you should too. Here was our thinking:

- Cheaper than a Tiptap enterprise license (essentially a 50% discount).

- Dramatically higher quality, in a way that is directly noticeable to users. The "naive" React/ProseMirror integration has terrible state tearing issues that make your text editor feel haunted. Cursors in weird spots, mismatched transaction errors, strange races that happen only sometimes, lots of `setTimeout` and `queueMicrotask` to patch over weird problems. The core issue is a little hard to explain, but React and ProseMirror both have a kind-of virtual representation of the DOM, and when that is updated, they figure out what changes need to be made to the DOM, and then execute them. But these cycles are completely incompatible. The solution is to rewrite the ProseMirror `EditorView` in pure React, which is what `react-prosemirror` has done. Tiptap did not do this, and it is empirically very challenging to manage as a result. I am happy to discuss more if people are interested.

- Collab on ProseMirror is in a very challenging spot, and this is the right team to work on it. Since we spend > $10k/yr funding the project, we have worked with them directly on this, and we know. We wrote about the alternatives in a recently-popular HN thread: https://news.ycombinator.com/item?id=47359712 although as god is my witness, I 100% promise we did not coordinate this in any way.

- Shane is one of the best engineers working in the frontend today. You want his attention, and it is worth paying for.

antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
But Kevin, you never really answered the question of the article. Unless I need a truly-masterless p2p topology, why would I do all this stuff, including throw away editor intent around things like block split, just to use Yjs? prosemirror-collab and prosemirror-collab-commit already seem to do all the things the Yjs docs claim to do (unbounded offline writes that reconcile automatically, optimistic updates, tolerant of all kinds of failures), and they work with 100% fidelity to the underlying model. AFAICT, the only thing that you need Yjs for, is true p2p editing.

This is a serious question, and the question of the article. I am here to learn what you mean, please explain.

antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
The magic of CRDTs does not prevent this. They are in exactly the same boat as OT, prosemirror-collab and prosemirror-collab-commit. It can't be prevented. The problem is worse with CRDTs because they instantly destroy user intent in the conversion to/from their underlying representation, which is the XML document. See discussion with Marijn about, e.g., splitting blocks above.
antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
I do not know how to say this another way. No. Nothing in this article was created, edited, outlined, pre-drafted, suggested, or in any other way influenced by AI. AI did not write the words, it did not review the words, it was not a part of a pre-writing discussion that influenced the words. There is NO AI IN THIS ARTICLE OR AS AN INPUT TO THIS ARTICLE. If the article is an apple, then 0% of the apple is AI or AI influenced.

And let this be a lesson to you. You apparently do not have any ability to distinguish between these two kinds of thing.

antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
Actually, I think I agree with most of this... except the part where you think it's not clear-cut, ha ha. I meant that not as a comparison between OT and CRDTs, but as a comparison to prosemirror-collab. My opinion is that in the centralized server case, it is (unfortunately) basically better in every dimension.
antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
Ok Marijn I understand. I'm sorry I caused you an inconvenience. Of course, I know that implementing server-side prosemirror-collab is not entirely without problems (since we have done it) and take your point, which is correct. If I was to do this again I'd find a different way to say this than "40 lines of code."

With that said... I do not agree it is not "simple." Or at least, I think it is about as simple as it can possibly be.

antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
Just to be extremely clear: we pay for a lot of OSS software. We pay one individual project more than $10,000 a year. We would have paid for Yjs too, if we thought it was a good use of resources!
antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
Hi Joseph! Good to see you here.

Sorry, I see why this was confusing. What I'm saying is that because users perceive the results of OT, CRDTs, prosemirror-collab, etc. as data corruption, they require presence carets as a UI affordance, to steer them away from direct edit conflicts.

If you can't have presence carets, yes... likely best to have a diff view. And in our case, we use git/jj for this, rather than CRDTs.

For the "history of" stuff... in spite of the fact that we have our disagreements, I actually think it would be very nice to have Kevin and everyone else on the record long-form talking about this. Just because I am a non-believer doesn't mean it wasn't worth trying!

antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
Thanks Nick. I am aware. The blog post directly links to the PR you merged some days ago that (as I understand it) kicks off the effort. I also mention specifically I know you're working on it.
antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
Just tying up loose ends here, in this other comment I suggest that Kevin and I are not on the same page about the point I was making in the article: https://news.ycombinator.com/item?id=47422455

I will additionally note that I'm not making any point about performance in this comment either, though. "Perform" in this context is not about 60fps, it's about whether, like, plugins work.

antics··on Lies I was told about collaborative editing, Part 2: Why we don't use Yjs
Hi Kevin, author here, are you sure we are on the same page about what I'm saying in this article?

For example, the debugging section is NOT about debugging problems inside Yjs, it's about debugging one's own bugs while one is using something like Yjs or prosemirror-collab. I'm normally a happy gambler but I actually think the Yjs GC algorithm probably does do what it says... indeed, my complaint is that I specifically do not want that behavior. :)

Likewise, the point I'm making about performance is NOT that Yjs is "slow". I'm saying that it's empirically very challenging to meet the 16ms perf budget even in the simplest possible realistic collab scenario... and that because of this, it is (1) very unappealing and (2) in our experience, challenging to attempt to do this when you also have to do a pile of extra things that are unrelated to the task at hand, like translate `Transaction` to and from operations on an XML doc, and deal with all the consequences of messed up positions passed to plugins. I do understand you have your own benchmarks that give you the confidence to (without qualifications) claim that y-prosemirror "runs at 60fps". You really are not curious about why we think that's not the case?

If we can't get to a shared understand what is being said here, it's going to be very hard to talk about it at all. And on the two material points at stack in your response, I believe you have the precise opposite understanding of what was written. I'm happy to keep discussing but it feels like we're starting from scratch after this response, again.

← PreviousPage 2 of 16Next →