> He derided my attempt to use an AI summary to bridge a communication gap (I explicitly stated I'm not a programmer) as a "...stochastic parrot designed to produce lies instead of actionable information...".
I don't really have a dog in the race, but I think people should react this way to AI communication. They should be shunned and informed in no uncertain terms that they are not welcome to communicate any more.
Even that phrasing is kinda rude. "bridge a communication gap", presumably the gap between programmer and non-programmer, right?
He used AI as in he gave the AI the patch that regressed, asked the AI to "find the bug", and pasted that output.
This would be akin to walking up to the architect for a house, and saying "it's not my job to build buildings, but I tried to use this lego design to show you how to do your job. Look, the legos snap together, can't you do that with the house?"
Using AI to try and explain things to a subject matter expert, which you yourself do not understand, will come off like that, like you're second-guessing, belittling, and underestimating their expertise all at once.
And the architect tells them to submit a new blueprint of the plans otherwise they can't do anything - knowing quite well he's not an architect and can't do that ("Submit a patch").
Thats absolutely not what they asked for, no one was able to reproduce the issue, so they asked for clearer instructions on how to reproduce the issue and were met with hostility. It's not the job of OSS developers to debug someone else's scripts just to then start debugging the actual issue. This is the absolute bare minimum of any bug report, if you think there's a bug but no one else can observe it, in the first instance you have to assume it's something to do with their setup, until shown otherwise. The addition of not just wrong, but completely misleading AI summaries just makes the job of an OSS dev harder, they now have to start debugging the bug report itself to try to figure out whats parts are even facts at all (hint, most of the AI generated content was completely wrong, but sounded plausible).
Personally, the developers of both the LLVM and Mesa projects were far kinder and patient than I would have been, most OSS developers aren't just not paid to work on these projects, but are usually paid to work on other things. Taking up their time with this nonsense is very insulting to them, and the attitude that they owe the author anything at all is, as stated in the LLVM ticket, exactly what pushes many developers out of OSS development.
I have a nitpick about about how AI is supposedly "designed to produce lies." That's pretty clearly false, unless you really believe the creators of AI are intentionally spreading lies through their products and that was their intention from the start. Call them careless or their technology inherently flawed if you want, but neither means "design[ing]" liar technology.
This might have been too petty to comment on, if it weren't for the irony that an arrogant human asserting that AIs are fallible made his own logical error or exaggeration in the same sentence. Was he designed to produce lies too?
Edit: I'm not really defending a layman using AI to produce patches, but the OSS developer's characterization is an overreach in the other direction. It's not a very useful heuristic either; at some point AI content is not going to be labeled or obvious, so it will have to be carefully evaluated for correctness and good-faith intention the same as human-generated content is.
One of the very first examples published by GPT-2, the model that started the "too dangerous to be open anymore" trend, was a fake news article about the discovery of unicorns in the Scottish mountains. It's been part of OpenAI's narrative since the beginning.
Agreed, but this needs to be codified in the CoC, otherwise people will use it to rules-lawyer and treat morally correct anti-AI bias as a character flaw.
I think it’s because it would be so easy to make a recursive page that includes itself forever. So you have to have rules when it’s okay, and that’s more complex and opaque than just programming it yourself.
This is interesting, but the syntax doesn't seem to have the right expressiveness for such a large change.
for recursive (Node t = tree.root; t != NULL;) {
puts(t.value);
if (t.value == target) break;
if (t.value == dontfollow) continue;
if (t.left) continue t.left;
if (t.right) continue t.right;
}
return t;
Regular 'break' is to really break out of the structure like a regular for, as regular 'continue' is to do the next iteration. But if continue has a value to recurse on, it reenters the for loop like a subroutine.
As a bonus, I think this is tail-call-optimization friendly.
DFS is pure flow control, like iterating an array. BFS isn't really the same simple deal as DFS, it either requires approaching the next level and saving it for the next depth somewhere, or navigating the entire previous level again.
This is interesting, but the syntax doesn't seem to have the right expressiveness for such a large change.
for recursive (Node t = tree.root; t != NULL;) {
puts(t.value);
if (t.value == target) break;
if (t.value == dontfollow) continue;
if (t.left) continue t.left;
if (t.right) continue t.right;
}
return t;
Regular 'break' is to really break out of the structure like a regular for, as regular 'continue' is to do the next iteration. But if continue has a value to recurse on, it reenters the for loop like a subroutine.
As a bonus, I think this is tail-call-optimization friendly.
Your zero-argument "continue" is Tyler's "prune", I think. At first glance I agree that something like your one-argument "continue" would also be helpful — like, "recurse but only down these k of the n possible child branches." That seems hard to find syntax for, unless you build the list of children ad-hoc as you go and then do "N : children)" in your increment step.
C is very much one level above assembly, the way dipping a jug in the river is one level above bending down to drink. It's a whole lot easier to mechanically translate *ptr++ = 0 to the corresponding machine code than to memorize and write those actual instructions. Neither is going to automatically check the security of your memory access through any more than the jug is going to test the water.
can you? There's a MAME driver in macprtb.cpp you could work off—might want a few hacks in your implementation which is nothing new to Mac emulation. also this: https://github.com/evansm7/pico-mac
Came here to say something similar. A laptop with a high quality transflective screen (e-ink is a touch too slow) that can run classic Mac OS with absurdly long battery life would be a nice little device.
reply