IME a vastly more common sentiment among mathematicians regarding mathematical talent leaving the nest to apply their skills in other fields is that those other fields are lucky to get them!

[1] https://arxiv.org/html/2605.20695v1

Writing off Erdös’s problems as random, useless, or meaningless dismisses his mathematical intuition, second-to-none, and strikes me as somewhat uncharitable.

Finally, I agree that AI threatens mathematical training by rendering an entire class of acolyte-level research problems solvable by prompt. But the Unit Distance Problem is not of this class.

I think the machine learning community was largely over overfitophobia by 2019 and people were routinely using overparametrized models capable of interpolating their training data while still generalizing well.

The Belkin et al. paper wasn't heresy. The authors were making a technical point - that certain theories of generalization are incompatible with this interpolation phenomenon.

The lottery ticket hypothesis paper's demonstration of the ubiquity of "winning tickets" - sparse parameter configurations that generalize - is striking, but these "winning tickets" aren't the solutions found by stochastic gradient descent (SGD) algorithms in practice. In the interpolating regime, the minima found by SGD are simple in a different sense perhaps more closely related to generalization. In the case of logistic regression, they are maximum margin classifiers; see https://arxiv.org/pdf/1710.10345.

The article points out some cool papers, but the narrative of plucky researchers bucking orthodoxy in 2019 doesn't track for me.

Browser implementors use Shadow DOM extensively under the hood for built-in HTML elements with internal structure like range inputs, audio and video controls, etc. These elements absolutely need to work everywhere and be consistent, so extreme encapsulation and fixed api for styling them is an absolute must.

The Shadow DOM API is the browsers exposing, to developers, a foundational piece of functionality.

If you’re thinking about whether Shadow DOM is appropriate for your use case, consider how/why the vendors use it —- when an element’s API needs to be totally locked down to guarantee it works in contexts they have no control over. Conversely, if your potential use case is scoped to a single project, the encapsulation imposed (necessarily!) by Shadow DOM is probably overkill.

Web components are a decent way to make reusable UI, but if they don’t have strong encapsulation needs, you might avoid Shadow DOM.

Fortunately, my university has a good accessibility center that takes care of accommodation issues (large print versions of tests, etc.). I just send them my tests and they take care of it. It’s a great service, and absolutely crucial because I simply don’t have the time to customize assessments. I assume they would get in touch if they were unable to retrofit accessibility onto an assessment, but that hasn’t happened in my fifteen years of employment.

I posit that any composable version of sprinkles or the “island architecture” will closely resemble RSC.

Only a small fraction of apps will ever use the full power of the RSC architecture. However, the React team doesn’t build apps, they build primitives for building apps. And good primitives are composable.