jfultz

Zero-tolerance no-AI policies are tiresome. I get why people have concerns. No PR reviewer wants to review drek the submitter him/herself doesn't understand. And LLMs have been a disproportionate source for such drek. But the actual problem they're trying to solve should be low-quality submissions, rather than spending energy fulfilling some notion of AI-free purity.

The linked issue raised the complaint that a bit of text as a "wall of text" (implication, I guess, too many words, too little meaning). Maybe it was or wasn't. But being generated by an LLM doesn't make it a wall of text, and being written by a human doesn't make it not a wall (speaking as somebody who has been fairly accused at times of generating 100% human-made walls of text).

Contrarian take.

So, yes, it's amusing to see clear Claude-isms like "load-bearing", "outright", and "genuine" in a [very nice] bit of analysis like this. And there's a (maybe negative? or not?) argument to be made about the world being filled with more Claude-isms or LLM-isms in general.

But I think the data say a second thing which is just as interesting and an absolute positive for the typical source code base. Look at the clusters that shrank significantly. Most of what you'll see in there is just incomprehensible...not even English. Cluster 4 has, after "pullrequest", a bunch of seeming usernames in the top tier. Cluster 6 seems to have names of repositories or tags in the top tier. Cluster 9 has branch names in it.

Meanwhile, keep going through cluster 1 and you'll see words I don't consider Claude-isms that really, really grow in usage. Words like "died", "nothing", "worse", "ever" all have well over 10x growth. This tells me something else. That the average commit log was BARELY ENGLISH. And then the LLMs came along and made commit logs that were ACTUALLY ENGLISH.

I count this as a good thing. I don't know the cross-section of repos chosen for this analysis, and I get it...some repos are garbage/throwaway, some commits come from automated processes that generate uninteresting commit logs, etc. But I've been benefitting from my work team's actually explanatory commit logs when doing code/bug archeology for decades, when doing PR review for the last decade, and I've even seen LLMs benefit from it in the last year (granted, not as often). A large part of professional software development is communication, and while the most important communication is via the code/comments, the commit logs are not unimportant. So, if this is making the average GitHub PR better (arguably more professional) by including actual English descriptions of code changes in commit logs...well, that's a genuinely load-bearing concept for me. :)

This is a really impressive amount of effort. Every entry has a fairly even quality to it...screen grabs and contextual descriptions of even one-off episodes of television shows, yet alone decades worth of movies.

In some cases, reviewing PR diffs commit-by-commit (and with the logs as the narration of the diff-by-diff story) is a substantial improvement over reviewing the entire PR diff. Concrete examples...

* A method or function that has code you realize needs to be shared...the code may need to be moved and also modified to accommodate its shared purpose. Separating the migration from any substantive modifications allows you to review the migration commit with the assistance of git's diff.colorMoved feature. It becomes easier to understand what changes are due to the migration, and what changes were added for more effective sharing.

* PRs sometimes contain mechanical work that is easy to review in isolation. Added or removed arguments, function renames, etc. No big deal if it's two or three instances, but if it's dozens or hundreds of instances, it's easier for the humans to review all of those consistent changes together, rather than having them mixed in with other things one has to reason about.

* Sometimes a flow of commits can help follow a difficult chain of reasoning. PR developer claims that condition X can never occur, but the code is complex enough that it's difficult to verify. However, by transforming the code in targeted ways that are possible to reason about, the complexity might be reducible to the point where the claim becomes obvious. One frequent example I see of this is of function/method arguments that are actually unnecessary, but it wasn't obvious until after some code transformations.

"Quality ratchet" is such a great name. Thanks for that.

I'm not willing to cede the point on hardware design for as long as their primary mouse product cannot be charged during use. It's such a simple and obvious mistake, like a throwback to the days of hockey-puck mice.

I left Slashdot for HN...but I didn't leave Slashdot because of HN. I was frustrated with Slashdot and was actively seeking alternatives. About 2 days after I discovered HN existed, I was done forever with Slashdot.

Among other frustrations (including some really vile comments), I felt like the world was bursting with interesting tech news, and Slashdot was just not keeping up. The publish rate was too slow (maybe 10-13 stories a day), and the %age of stories I found interesting had dropped considerably from a few years previous.

I wasn't a fan of the redesign, but it was content that drove me to seek alternatives.

Growing up in the 70s, among the things I sought out in our house to play with was an old manual typewriter. It was endlessly fascinating to me. I liked playing with all of the mechanical bits. Trying to jam keys, working the carriage return, scrolling paper through it, pressing the Shift key and looking to see how it moved the entire basket of typebars, overtyping to make new characters, watching how the ribbon advanced with each keystroke and rewinding it by hand, etc. One thing I had forgotten, which was mentioned in this article, was figuring out how to set tab stops, which allowed me to either stutter the carriage across, or make it fly free from one end to the other.

An alternative to securing or recreating the entire technology stack top to bottom would be to own one critical piece of the stack. If European interests owned a vital slice of the technology stack that was difficult to recreate and too cheap/convenient to not be used by international government/business/consumer interests, that could be a powerful deterrent. I.e., it sets up a "mutual assured destruction"-style defense.

The 1200XL was my first computer. My family purchased it at a department store at a fire sale price (IIRC Montgomery Ward's, $199) after Atari stopped manufacturing and began dumping its inventory to make way for the 600XL/800XL. I had been researching a computer to get for ages, but my family was very careful about how we spent money, and it was a big purchase. We had seriously considered getting a TI-99/4A when TI exited the business, but we were concerned that it was just going to be a dead end. But the chance for a cheaper entry into an established ecosystem was great (that and me begging my mother to finally, finally get a computer!).

Re compatibility, I never came across software that didn't run on it. I'd read in magazines that there were issues, but never once experienced it. One interesting software change, though (but true of other XL computers, too) was that the color "artifacting" worked differently on it than it did the 400/800. For example, Ultima III used color artifacting, and so playing it on my system produced some incorrect colors...most notably the sea was red.

I did come across one hardware issue...a cheap third-party parallel interface adapter that didn't work, and that we thought at the time was defective, but I now think it's likely to have been affected by the incorrect power wiring in the 1200XL's SIO adapter. It was cheap enough that we didn't lose too much money on it, and I ended up getting the far superior ICD P:R: Connection instead.

The Atari community was a super great community to be in. And in so many ways, Atari was doing things that wouldn't be seen again for years, if not decades. Atari's SIO port is famously a predecessor/inspiration of USB. The APX Exchange was basically a third-party app store decades before Apple popularized the concept. The machine was hackable and moddable (I bought a 256KB upgrade kit for mine). When I migrated to PC for college use, it hurt to have to fall back to CGA...even EGA was just ugly, compared to what my 1200XL was capable of (although the 80 column displays were nice compared to Atari's 40-column).

Solved, and it was fun! But...some of the colored lines were hard to see. Particularly the light yellow ones. I had one "alternate" solution that it was marking incorrect for reasons it took me over a minute to spot...and it was just a super light yellow line I missed without really scrunching up to my screen.

Improving the color choice might help, but slightly thicker lines I think would also be of significant help.

Also, it's common for sudoku solvers to allow you to press Shift+number to do a one-off toggle for the "note" checkmark.

Fortunately for me, you left this comment, so I upvoted the article and your comment. Which kind of scratches the same itch.

THIS!

I had hope at one point to set up a Kindle with large fonts on a treadmill, but that was just totally hopeless. I tried again with a music stand next to the treadmill, but it was too far away, badly angled, and touching the device to flip pages could still turn it off.

And it's not just the accidental power-off, it's also the accidental power-on. I slip the Kindle into a tight pocket in my backpack, and it sometimes turns on by itself. Further, inserting it into the pocket can sometimes reproduce the swipe motion, so it can be on and active (and sometimes randomly page-flipping) inside my backpack.