eslaught

I am on two program committees for major CS conferences this year.

LLM writing is horrible, full stop. The vast majority of papers that I see with obvious LLM writing ticks are also frankly incomprehesible. Claude's biggest sin at the moment is inventing new terminology (sometimes multiple times in a single sentence!) without stopping to explain what it means.

In previous years, I would see a substantial fraction (maybe 30-50%) of papers that were obviously written by non-native English speakers, and full of grammatical mistakes and typos. I have seen zero papers like that this year. Honestly, I preferred those: reading LLM writing is painful by comparison.

So far I have seen exactly one paper that had obvious LLM writing ticks, and yet had gone through enough passes (either of the LLM or the human authors) that the paper itself was comprehensible. So I'll admit that it's possible to do. But based on what I've seen this is vastly in the minority.

I honestly used to enjoy the review process; even when the papers were bad at least I could usually see the effort that went into it and give some constructive guidance on how to improve. The process is dramatically less pleasant now, and it's not obvious if I'm accomplishing anything: if authors who write with LLMs just stick the reviews back into those same LLMs, will they learn anything? I suspect not.

Maybe some day LLMs will be good enough to write, but as of today: please, please, just don't do it. The typos and grammatical mistakes are easier to read than the slop.

You're missing the biggest suggestion from the GP's post: that the key to LLM success is verifiability.

Software has high verifiability through compilers, linters, static analysis, leak/memory corruption detection tools, or the very least, running the program to see if it crashes.

Math (as has been making the headlines recently) has high verifiability through automated theorem provers. Notably some of the non-mechanized math results from LLMs have been demonstrated to be wrong (and presumably many more are being checked; these aren't exactly easy to understand proofs).

Game playing (chess, go, Star Craft, etc.) is similarly verifiable: you get your score and you always know how you did in the end (even if not in the moment).

Making assumptions about LLMs in non-veriable domains is making a claim about LLMs that doesn't match their current capabilities. Maybe they'll get there and maybe they won't; I can speculate as well as you can but we're both guessing, so I'm not sure how much value the speculation has.

As far as I can tell, you're essentially creating a new stack for every dynamically-sized variable (because otherwise nothing would be able to grow by bump allocation without moving). But this means you're creating a separate virtual memory allocation for each of these objects, which (I presume?) then rounds the size up to the OS's minimum page size (4KiB or similar).

Doesn't that waste a lot of space? Or is there something I'm missing?

Also it would seem to force every allocation to go through the OS kernel to allocate unless there's some trick to avoid that.

One aspect of trauma is the helplessness of it: it's not just how severe the physical reality is, it's also about the inability to do anything about it (and the internalization of that inability).

The classic example is a child who drew a picture shortly after 9/11. The picture included people floating down the building on (I believe) balloons or umbrellas. Obviously unphysical; but the child imagining ways (however fantastical) that could have helped was a factor in reducing that child's trauma.

On a therapist can tell you whether you personally have trauma, but the lessons you took away from your experiences certainly sound like it to me.

What's better about it in your usage?

Why not? Cargo.lock includes the transitive dependencies, and Cargo itself reports everything that changes when you do an upgrade. Those are version changes, not code diffs, but it seems entirely tractable.

In what sense is AI like paying for ads? In one case you legitimately lose to the competition if you stop (prisoner's dilemma). In other case, whether and how much you lose depends almost entirely on how much it actually impacts your productivity in practice (or not).

If you're referring to the public perception benefits (supposing those even exist, which isn't clear to me), then it seems easy to make a lot of noise via PR while doing the minimal amount internally to explore the use case and not actually push it as hard as you say.

And how do you get this to work exactly? I keep getting variations of "Missing required parameter: redirect_uri" in the OAuth flow.

The solutions proposed by Gemini and Google's AI summaries all hallucinate agy subcommands that don't exist, hilariously.

Edit: after bouncing around several GitHub threads, I realized that the agy TUI framework is wrapping the URL in a way that causes spaces to be inserted where the URL wraps. That's hilarious.

Just popping in here because people seem to be surprised by

> I build on the exact hardware I intend to deploy my software to and ship it to another machine with the same specs as the one it was built on.

This is exactly the use case in HPC. We always build -march=native and go to some trouble to enable all the appropriate vectorization flags (e.g., for PowerPC) that don't come along automatically with the -march=native setting.

Every HPC machine is a special snowflake, often with its own proprietary network stack, so you can forget about binaries being portable. Even on your own machine you'll be recompiling your binaries every time the machine goes down for a major maintenance.