rwl
I don't have a good reference (other than the Elisp manual) for high-level design patterns, but in general, Elisp is very flexible and already has what you'd need to implement any patterns you know from elsewhere. Decide on your data structures first. Probably the most important lesson you might not know yet is to use buffers, not strings, to do most text manipulation.
For example, it's pretty easy to use CSS counters to create as many automatically incrementing counters as you need. Page number, section number, theorem number, etc. But (a) you can't do this in raw HTML, which means you can't rely on this working in any user agent that has poor support for CSS; and (b) you can't refer to the values of those counters outside of CSS. Thus, there's no way for you, as an author, to write the write the equivalent of LaTeX's "See Theorem~\ref{thm:foo}" in HTML and rely on having it auto-numbered and rendered correctly wherever your readers are. So the number has to already be there as text in the HTML, and you need a separate, document-unique id attribute coordinated with the number to use for linking. This means you need a separate compilation step to produce the HTML, so you've lost pretty much the only advantage that HTML had over LaTeX.
But fundamentally, the problem is that citation practices assume that the reading format is controlled by the author/publisher, so that all readers are looking at a common view of the document, whereas the Web assumes that the reading format is controlled by the user agent, and user agents vary widely. Thus, on the Web, you need formatting-independent citation practices, which have not yet evolved, or at least not become widely used, because it's too hard compared to page-based media, which have been working for centuries.
How to Build a Phyle
I wouldn't necessarily mind a dedicated piece of hardware, but if it's dedicated hardware, I feel like the bank ought to provide it, not make me pay for it. And I'd much rather it be a generic piece of hardware that can also be used as a second authentication factor for other things, like a Yubikey. I've looked around but have not found any banks that offer this. The only one I had heard of no longer offers it.
I'm sure most research mathematicians would like more freedom from some of the drudgery of their work (grading, admin, etc.), just like the rest of us. But we should be aiming for a world that allows more people to become mathematicians, not fewer.
The Issues with Issue Trackers
https://mail.gnu.org/archive/html/bug-gnu-emacs/2025-11/msg0...
This will add an iCalendar library to GNU Emacs, allowing packages in core and third-party packages to work with the format. More on the decisions I made and what I learned here:
Improving Emacs' iCalendar Support
AI and the Golem
This makes second order languages, including the language of arithmetic, much more expressive: they can distinguish models that first order languages can't. Those infinitely many non-isomorphic models of arithmetic expressed in a first order language can be distinguished, and excluded, as models of arithmetic expressed in a second order language. That's why second order arithmetic is categorical: all of its models are isomorphic.
Yes, a model of second order arithmetic contains a model of first order arithmetic, but within the second order language, you can say "which model it is" (up to isomorphism). It's only if you restrict yourself to a first order language that you can no longer say anything which will be true in that model, but false in any non-isomorphic one.
This completely agrees with my own experience. But if these things are true when viewing a "dispersed content" site on a desktop browser, shouldn't they be just as true on mobile? It seems to me that this is a big problem with mobile-first design in general: it's just not the right format for actually conveying conceptual information to users.
Symbolics
Earlier this year I came across this study with very promising results:
Sirh, Soo Ji, So Woon Sirh, Hah Yong Mun, and Heon Man Sirh. 2022. “Integrative Treatment for Tinnitus Combining Repeated Facial and Auriculotemporal Nerve Blocks With Stimulation of Auditory and Non-Auditory Nerves.” Frontiers in Neuroscience 16. https://www.frontiersin.org/article/10.3389/fnins.2022.75857....
They found an acupuncture-based treatment which eliminates or significantly reduces tinnitus in more than 87% of cases (n=55). I'm hoping to be able to get this at some point. The study is out of South Korea though; it might be a while before the technique is available in the west.
I saw a photo exhibition [1] about the construction of the Bay Bridge once, containing many beautiful shots from the point of view of the workers. The photos were taken by Peter Stackpole, a 20 year old kid who basically just talked his way onto the boats that took the workers out to the site. He took photos of the towers as they were being riveted together, of the cables being wound. The photos are amazing and beautiful, but they show how dangerous the working conditions were.
When someone fell off and died, the workers would take the rest of the day off, but be back on the job the next day.
We don't accept that kind of risk anymore in the US, which obviously drives up construction costs. But it's hard for me to see that as a bad thing, and I bet that if you went and talked to the "builders" today, they'd prefer those costs to the ones we paid in the 1930s.
[1]: https://museumca.org/exhibit/peter-stackpole-bridging-bay
https://github.com/beakerbrowser/beaker/discussions/1944
https://atek.cloud/blog/hello-world
This is a great idea, but the big problem with Beaker is the network effects: only Beaker users can see other Beaker users' sites. To be successful, I think the idea needs to run over regular HTTP(S) so that other browsers can still access these personal sites. This means, at least at the beginning, that someone needs to run the infrastructure that maps stable URLs to a P2P connection to individual browsers. Mozilla is in a good position to do that.
Given the values outlined here, I was sad to see that Mozilla doesn't seem to be looking much beyond the centralized platforms of today's commercial web. They see the "minimal barriers to entry for both users and publishers" as one of the key properties that makes the web such an important communication medium, and "Site-Building Ergonomics" is a top-level area where they see possibilities for improvement. Despite this, I don't see any recognition that it's still too difficult for ordinary users to publish their own information, which is why we have big commercial platforms where people do this, funded by ads, with all the problems that come along with that.
I think the most revolutionary thing Mozilla (and other browser makers) could do to realize this vision would be to turn their browser into a publishing platform. Browsers already have excellent tools for editing HTML, CSS, and JS built in, and they already speak the relevant protocols. Why not give every user a base URL for their personal site, and serve pages under it directly from the browser running on their computer? That would really lower the barrier to entry for users to become publishers and help realize the values of Openness and Agency.
Of course, such sites wouldn't be available 100% of the time, but they would probably be available enough to cover most of things people use the big platforms for: sharing text, photos and videos with their family and Internet friends. They would not need to be ad-supported and wouldn't raise the associated privacy issues. There are other problems to solve, but Mozilla is uniquely qualified to solve them.
The very first web browser had this feature: https://en.wikipedia.org/wiki/WorldWideWeb#Features And it seems the perfect way to realize much of this vision. Why not bring it back?
But there are still huge, important differences between public transport and "ride sharing". Public transportation almost never takes you point to point. You are expected to navigate public transportation on your own, including getting in and out at the right stops. Public transportation usually has sharply reduced service several hours before bars close. You also need a ticket, which often means you must be sober enough to work a machine that only takes cash.
If public transport is your ride home, you need to be a lot more sober than the people the author is writing about.
There are important differences compared to taxis, too. To take a taxi, you must (often) be prepared to pay in cash. You must have enough verbal control to give your address.
It is not implausible that ride sharing apps enable a kind of binge drinking that is qualitatively different from the kind people do when they have to take another way home.