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).
No because some people are against AI for reasons other than just slop. Some people actually find it revolting that it uses so much energy and that it encourages deskilling in many. AI in my view is antithetical to human creativity and I try very hard to avoid software projects that use AI, whenever possible. And I try to only promote software that is AI-free.
Don't forget ethical concerns about using things that only exist because of boatloads of criminal behavior.
Some people are tired of situations where 14 year olds get hounded for years for downloading music but altman/amodei/musk/zuck get billions and zero consequences for stealing more copyrighted content than any individual ever could in a lifetime.
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.
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.
Not to mention its ergonomics issues. I held onto mine as long as possible because I loved the capacitive shell. Eventually I had to ditch it though to keep my wrist healthy.
The comic pokes fun at the ridiculously cruel babelfish puzzle. Which, I'm proud to say, I solved back in the day without assistance, after a full day's worth of effort, and requiring at one point to completely restart the game because of an apparently useless item I didn't pick up at the very beginning of the game (if you've solved it, you'll know the item I'm referring to).
But...while that was a nice achievement, I still got stuck later in the game, trying to fix the Nutrimatic.
I'm not aware of Invisiclues ever having been "installed." I'm only familiar with them as booklets with "invisible" ink. And, at least initially, they were created at least quasi-independently of Infocom by someone who later joined Infocom.
May have been re-releases. I had a lot of the original games with feelies and (effectively) anti-pirating code wheels and the like. I think I have one of the CD re-releases and I play for a bit now and then with a Z interpreter.
Yes rereleases as I stated above. ( or meant to ) I recall my father being quite excited when he saw them. Not sure what games he played first on the Commodore, if any.
They amused me for a time at 9-10, then later at maybe 14-15 or so I got into them again playing on a Palm VIIx with a folding Stowaway keyboard. I also read through HHGTTG on that same device.
I have fond memories of some z-machine interpreter on the Palm that I found easier to play with than anything on my desktop computer. There were lots of shortcut buttons and thanks to the stylus it was still easy to use those (vs a touchscreen using ony fingers where you need huge buttons to hit). You could also tap any word in the output to bring up a context menu of actions (e.g. to examine or pick up objects mentioned in room descriptions) and that list of actions was a combination of a configurable global list and a game-specific list you could add actions to. Could play through entire games and barely ever have to type anything. Had a folding keyboard, but no memory of using that for interactive fiction.
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 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).
reply