nimih

Maybe it's different in your neck of the woods, but all the government portals I use tend to have access to rather sensitive PII, and I would really prefer their ops teams be up to snuff as a result.

I'm not sure I really agree with your main point (I think it's probably still important for LLM-generated code to be generally human-understandable, at least if you care about long-term maintainability), but setting that aside to answer this question:

> I guess you would code manually every now and then for your own enjoyment but at that point do you care about style guides written for scale?

I think they're still quite valuable in that case, for a couple reasons:

- When learning a new language (which happens much more frequently when writing code "for pleasure," as it were), "written for scale" guidelines still translate pretty well to "written for oneself" IME. At the very least, they tell you what to expect in code you read, and give you a reasonable starting point as you develop your own taste and stylistic preferences.

- I've noticed some open source projects beginning to institute anti-AI contribution guidelines, and such projects still benefit from codified style guides. Google obviously doesn't fall under this category themselves, but in other language ecosystems, their style guides tend to find use in OSS projects.

Idk, it also has a nicely expressive typesystem outside of lifetimes, a lot of modern syntactic features like pattern matching and monadic error handling, well-written compiler error messages, a well-designed standard library, and substantially less accrued cruft when compared to its largest competitor. Safety might be the cudgel its evangelists like to beat everyone over the head with, but there are certainly things to recommend it outside of that.

That is, in fact, the page I started on. But the firmware on my paperwhite 2 kindle is so old (and also can't be logged in to my Amazon account) that I couldn't get the provided instructions to work, so I had to go spelunking on the wiki to find an ostensibly obsolete jailbreak that did work for me.

I dunno, I'm a kinda-dumb web developer who's spent the past 9 months deep-frying my brain with LLM model output, and it also took me multiple hours (but, less than a day) to figure out the right jailbreak for my kindle and how to run it. I think that's probably just how long it takes to find what you need on the kindle jailbreaking wiki and carefully follow the instructions, regardless of what other skills and preexisting knowledge you may have.

I'm not sure what the point you're trying to illustrate is, but I think you forgot a `flip` (unless the point is that you always mix up the argument order of the foldr reducing function, in which case fair enough).

you probably shouldn't complain about people "screeching" when this is the tone you respond to calm, measured discussion with.

part of the charm of letterboxd is that its median reviewer is far more woke than every NYT contributor combined, imo.

This paper doesn't seem to have much to do with post-modernism at all; it strikes me as much more in line with modern analytic philosophy.

Nor does it make any claims about the nature of intelligence, for that matter.

Did you even read the abstract?

FWIW, I'm only half-joking with my comment: dealing with software updates is an annoying part of life, and IMO rsync's UI is rather complicated (in that it's easy to use the wrong set of flags and do the wrong thing, sometimes in annoyingly subtle ways) and I basically always need to refer to the man pages (or, these days, an LLM, followed closely by the man pages to sanity-check what I'm doing) whenever I'm writing a new incantation of it rather than copying from an existing script or my shell history. I just chafe a little bit at declarations like "better than," since that's clearly not true (in the same way that rsync is not unequivocally "better than" syq), when more precise and less conceited descriptors like "faster than" are sitting right there on your benchmarks page.

Browsing the repo, I can see a couple of advantages:

- Single contributor. Software bugs are generally caused by developers writing code. By reducing the number of contributors, syq has cleverly reduced the surface area for defects to sneak in.

- Distribution via shell script. rsync is bundled in most linux distributions, which means you have to deal with annoying software updates from time to time. Syq, OTOH, tells you to pipe curl into bash to execute a shell script, which means one-and-done installation and maintenance.

- UI clarity. If you search StackOverflow for rsync, you'll see thousands of questions asking how to accomplish various tasks with rsync, both straightforward and arcane. By contrast, `syq` isn't even a tag on SO. The obvious conclusion here is that rsync's interface is so byzantine, and its documentation so poor, that users must resort to asking strangers for help, a problem obviously not shared by syq.

By "information dense," I meant in contrast to what is typical in modern GUIs: generous borders and margins between interface elements, large buttons, etc. My experience both using and writing TUIs is that, because of the extreme limitations of your tools w/r/t styling and layout, more of the screen real estate tends to be devoted to displaying data, and on whole I prefer that.

YMMV, of course, I'm just sharing my own experience and perspective.

I personally like making (and using) TUIs because:

- They encourage developing simpler, information-dense, and keyboard-driven interfaces, which I tend to prefer in general.

- I find them more fun to write, and less aggravating to maintain and debug, than interfaces built with GUI toolkits.

- Most software I write for personal use is going to be run in both a Linux and Mac OS environment (and a lot of the time on a headless server to boot), and a TUI often has less fuss than other options (at least, IME).

- I think monospaced text in a terminal just looks cool.

One way to get around this in some cases is to subscribe to the feed's associated email newsletter, which, IME, is more likely to have the full text of the article. This, of course, introduces other problems[1], but if your goal is to remove reasons to habitually look at your phone, it's worth investigating.

[1] The feed needs to have a newsletter in the first place, you probably need to clean up the markdown a bit before shoving it into an epub (I've noticed that table-based layouts are much more common, for instance), and your email provider probably doesn't provide an RSS feed of your inbox. The latter two are straightforward to fix but do require a bit of programming elbow grease.