• 0 Posts
  • 8 Comments
Joined 2 years ago
cake
Cake day: July 1st, 2024

help-circle

  • I’m not sure I totally understand your comment, so bear with me if I’m agreeing with you and just not understanding that.

    “let me prioritize PRs raised by humans” … but why? Why do that in the first place? If bots/LLMs/agents/GenAI genuinely worked they would not care if it was made or not by humans, it would just be quality submission to share.

    Before LLMs, there was a kind of symmetry about pull requests. You could tell at a glance how much effort someone had put into creating the PR. High effort didn’t guarantee that the PR was high quality, but you could be sure you wouldn’t have to review a huge number of worthless PRs simply because the work required to make something that even looked plausibly decent was too much for it to be worth doing unless you were serious about the project.

    Now, however, that’s changed. Anyone can create something that looks, at first glance, like it might be an actual bug fix, feature implementation, etc. just by having the LLM spit something out. It’s like the old adage about arguing online–the effort required to refute bullshit is exponentially higher than the effort required to generate it. So now you don’t need to be serious about advancing a project to create a plausible-looking PR. And that means that you can get PRs coming from people who are just trolls, people who have no interest in the project but just want to improve their ranking on github so they look better to potential employers, people who build competing closed-source projects and want to waste the time of the developers of open-source alternatives, people who want to sneak subtle backdoors into various projects (this was always a risk but used to require an unusual degree of resources, and now anyone can spam attempts to a bunch of projects), etc. And there’s no obvious way to tell all these things apart; you just have to do a code review, and that’s extremely labor-intensive.

    So yeah, even if the LLMs were good enough to produce terrific code when well-guided, you wouldn’t be able to discern exactly what they’d been instructed to make the code do, and it could still be a big problem.


  • But then you’ve got a space that’s 5’ 7 3/8" and you need a clearance of 7/32" on each end, so your piece should be…uh… 5’ 6 15/16" long. So much easier than metric, right?

    In metric it would be 1711mm (or 1.711m) and you’d need to take 5.5mm off each end, so it’s 1700mm. (For the record, I picked random numbers in imperial and only did the metric conversion afterwards, I just lucked into the nice round number here.)

    I dunno. You need how many sig figs you need in whichever system, but switching between a factor of 12 for the feet, base 10 for the inches, and the equivalent of binary decimals for the partial inches sure does take getting used to. I’ve finally gotten used to it enough that I can do it in my head, but I prefer to work on metric for most things.

    I acknowledge that machinists just use thousandths of an inch, which does greatly improve working with that system, but it also introduces a third kind of measurement that can’t easily be interconverted with the other two. I dunno. It just feels like we’re doing way too much work propping up this archaic system when literally everyone else in the world is using something simpler and we could just be on the same system.




  • Haha, that’s giving me way too much credit. I was a high school student and was still figuring out what the GUI bits did, like the ArcBall widget, so I practically couldn’t do anything useful on the GUI itself on days when I didn’t have a GUI machine. I could do some of the behind-the-scenes linear algebra stuff, though. Like, there was an array that held a 3d vector at every point in space that represented the flow field, and they wanted to be able to visualize cross-sections, so for that I needed to make a 2d grid of 2d vectors on a single plane. That sort of thing basically had to be done blind anyway.