My reading was "There is (too) much to say all that pain he wrought on me, all there sour and all that sorryness. Not shall I never forget, not while I live!"

David Metzler has this really cool playlist "Ridiculously Huge Numbers" that digs into the details in an accessible way:

https://www.youtube.com/playlist?list=PL3A50BB9C34AB36B3

By the end, you're thinking about functions that grow so fast TREE is utterly insignificant. Surprisingly, getting there just needs a small bit of machinery beyond Peano Arithmetic [0].

Then you can ponder doing all that but making a tiny tweak by replacing succesorship with BB. Holy cow...

[0]:https://en.wikipedia.org/wiki/Theories_of_iterated_inductive...

By default, you get snapshots every minute for the last hour, every hour for the last day, and every day into perpetuity. This is configurable. You can set as many cadences as you wish, with the ability to configure their frequency and lifetimes.

Actually, snapshots are like btrfs volumes in many ways, meaning they can be mounted, read from, and written to as desired. This allows the filesystem root to just be another snapshot with a default backup cadence as described above.

The gefs(4) manpage [0] has more info for those interested. It's a short and sweet read. The source [1], is under 12k lines of well-written code, comments and whitespace included. The author is also extremely responsive to issues and a pleasure to talk shop with.

Anyway, given the parsimony of the OS and the small community size, I find 9front to be a really nice incubator for playing around with new ideas.

[0]:https://man.9front.org/4/gefs [1]:https://git.9front.org/plan9front/9front/front/sys/src/cmd/g...

I randomly stumbled across this series that incrementally walks through the construction of truly gargantuan (computable) numbers. The fact that this touches on deep areas of math feels unexpected and fascinating.

Just wanted to share.

Comments URL: https://news.ycombinator.com/item?id=46688257

Points: 1

# Comments: 1

So behavior of the system fails to meet its design goals? It honestly sounds like you kind of agree with the excerpt you quote.

> The expansion of the federal government ... [is] what needs to change

What are you proposing though? Even assuming the premise here, achieving said goals requires changes to lots of little details and incentives. It's not like there's a single potentiometer controlling Gov't Size™. So what are you actually suggesting?

Certainly, the details of fundamental electoral structure engage deeply with the operation of our government, and the legal scholars in the article seem to be honestly pointing out levers (and big ones at that) we could possibly pull to create a less expansive federal government, or whatever the goal may be.

Imagine a plane crashes and analysts start attempting a root cause analysis, discussing control system specifics and whatnot. To me, your stance reads like "This is by design. Plane parts are united but independent. Control systems were never intended to lord over every part of the plane. The expansion of control systems is what needs to change."

I mean... maybe? But even if we agree on that point, any random contraction of the control system seems unlikely to make a plane that flies better. We have to actually engage with the details of what's going on here.

  - Window resize works as expected,
  - Doesn't lose input focus on resize or move, and
  - *Dyamic* scaling.

https://github.com/Seeker04/plwm

It actually has quite good UX affordances. More than that, however, I find the code imminently hackable, even as someone with very little Prolog experience. Reading through the plwm code really demystified the apparent gap between toy and practical Prolog for me. Heck, even the SWI-Prolog codbase itself is quite approachable!

I'm also mildly surprised at some of OG's gripes. A while back, I ran through Triska's The Power of Prolog[0], which crisply grounds Prolog's mental model and introduces standard conventions. In particular, it covers desugaring syntax into normal predicates, e.g. -/2 as pairs, [,]/2 as special syntax for ./2 cons cells, etc. Apparently, I just serendipitously stumbled into good pedagogical resources!

I'd be interested in ways that people utilize logical programming concepts and techniques into non-LP languages.

[0]:https://www.metalevel.at/prolog

https://sliderulemuseum.com/

Last year I picked up a bamboo Hemi and worked through the (70yo!) workbook. The trigonometric scales are cool. Making a single slide to find all the sides of a triangle is surprisingly satisfying. It got me to realize that, sliderules with the right scales can solve the roots of any 3-variable equation. I guess this is why there was a proliferation of industry-specific sliderules back in the day.

More generally, aren't simple, well-engineered analog tools so satisfying?

  - Main developer is blind, so accessibility has priority;
  - Easily scriptable; think automating captive portal clickthroughs;
  - Reading articles (e.g. Wikipedia) feels closer to reading a book;
  - It even supports JavaScript to a degree!
  - The affordances of line-oriented editing carry over nicely.

The main developer appears to tinker on the project daily and is quite nice to chat with over on libera's #edbrowse. The project does have a small, dedicated following, but I wish more people knew about it!

[0]:https://github.com/edbrowse/edbrowse

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

One use case I've not seen covered is sending blobs asynchronously with forward secrecy. Wormhole requires synchronously communicating the password somehow, and Signal requires reasonable buy-in by the recipient.

Basically, I'd like to just email sensitive banking and customer data in an encrypted attachment without needing to trust that the recipient will never accidentally leak their encryption key.

Just to add context to a sibling comment, Japan's first "writing system" was literally just Chinese.

I don't mean Chinese characters, I mean that if you wanted to write something down, you had to communicate in written Chinese. Over time this written Chinese accumulated more and more transformations bringing it in alignment with spoken Japanese until we get what we see today. However, this means that, to a first approximation, modern Japanese is some amalgamation of Old Chinese and Middle Japanese.

Actually, use of Chinese co-existed alongside the whole transformation process, so we actually see this funky mix of Early and Middle Japanese with Wu, Han, and Song Chinese. Character readings varied by region and time period, and so the the reading of a compound kanji term in Japanese mostly reflects the time period when that word was imported. This is why a single kanji ends up having multiple readings. Later, people began backporting individual characters onto native Japanese words, giving yet another reading.

The character 行 is a particularly illustrative example: 行脚 (an-gya), 行動 (kou-dou), 行事 (gyo-ji). The first reading "an" comes from 7th century Chinsese or so, "kou" comes a bit later from the Han dynasty, and "gyo" even later from Song. Then we have the backports: 行く末 (yu-ku-sue), 行く (i-ku), 行う (okona-u). The first "yu" reading is from Middle Japanese, "i" from Modern Japanese, and "okona" from I have no clue when. That's six different readings for 行 alone!

Oh, and then there are "poetic" readings that are specific to usage in people's names: 弘行 (hiro-yuki) etc. Granted, these are often quite evocative of the above readings or that of synonym characters.

The historical introduction process also explains why older readings tend to be more obscure, 1) they had less time to accumulate usage, and 2) they tend to be specific to Buddhist and administrative themes.

Note: The above is just what I've pieced together osmotically over the years, so I'm sure there are errors.

Also, you're excited by Forth and Lisp, you might like Forsp[1]. It uses a call-by-push-value evaluation strategy in a way that really makes the language feel like a true hybrid of the two. The implementation is also brilliantly simple.

Anyway, thank you for the article. I lurk on the DuskOS mailing list and wish I could find out where the Forthers gather IRL so I could osmote more of their world into my own.

[0]:https://dacvs.neocities.org/SF/

[1]:https://xorvoid.com/forsp.html

This is so real. I had the same issue and was only able to break through by collabing with professional APLers. It's very non-ideal for the curious autodidacts.

I'd love to share, hone, and flesh out what the Tool of Thought looks like in practice with interested others. For anyone here to whom that sounds fun, feel free to reach out. Contact info is in my profile.

That said, it's specifically written for an audience that is familiar with YAML detail in particular, parsing more generally, and of course APL expressions of ideas. In fact, that is a big part of what makes the code readable and maintainable: it is optimized for communicating to the expert worker not for on-boarding new developers. The latter is more appropriately handled via other means IMHO.

The poster child for this style of APL is Co-dfns[0]. It's a production APL compiler and a much larger example of the code I'm talking about. The entrypoint to read is cmp/PS.apl.

If you're interested, I'm willing to have a chat and talk more about what makes this kind of APL imminently workable, in which case there are also some personal private examples I could share as well. Feel free to reach out to the contact info on my profile here.

[0]:https://github.com/xelxebar/dayaml/blob/master/Y.apln.

[1]:https://github.com/Co-dfns/Co-dfns

My experience is with APL, but I think it is capable of producing some of the most readable and maintainable codebases out there. I've worked for years in various projects using Python, Java, C, Scheme, and a smattering of many other languages. However, it's really hard to overstate the clarity that comes from data-oriented design and dogged elimination of API boundaries.

It just takes a long time to learn to write good software in good APL style. In many ways all the in vogue best practices these days around declarative and functional programming tend to work antithetically to writing good array code. This means that the learning curve for experienced programmers is, perhaps paradoxically, higher than that of a totally naive beginning coder.

I really wish I knew some way to directly convey the experience of working with APL at a high level. There's really nothing else much like it.

This is the main insight in my breakdown of the J Incunabulum:

https://blog.wilsonb.com/posts/2025-06-06-readable-code-is-u...

When I first encountered it years ago, the thing was impenetrable, but after learning APL to a high level, it now reads like a simple, direct expression of intent. The code even clearly communicates design tradeoffs and the intended focus of experimentation. Or more on the nose, to me the code ends up feeling primarily like extremely readable communication of ideas between like-minded humans. This is a very rare thing in software development in my experience.

IMHO, ideas around "readable code" and "good practices" in software development these days optimize for large, high-turnover teams working on large codebases. Statistically speaking, network effects mean that these are the codebasese and developer experiences we are most likely to hear about. However, as an industry, I think we are relatively blind to alternatives. We don't have sufficient shared language and cognitive tooling to understand how to optimize software dev for small, expert teams.

AFAIU, btrfs effectively absolves itself of responsibility in these cases, claiming the issue is buggy drive firmware.

https://www.crowdsupply.com/modos-tech/modos-paper-monitor

It's just a dev kit run, but I've got high hopes for the whole Modos project.