Gaslight-driven development • Hacker News Board

Re: Gaslight-driven development

#111

Post by hi_hi » Thu, Jul 17, 2025, 10:11 PM UTC

Dilettante_ wrote: post #96

hi_hi wrote: post #95

Earlier quoted context omitted.

What would be an appropriate response code for "He might be a teapot, or he might be chiding me for misusing llms or he might be signaling that the monkey is out of bananas or [...]"?

Each of those should have a clear, unique response code. There should be no "maybe it's this, maybe it's that". A real-world example is login forms that tell you something like "Invalid e-mail or password". Are you joking around with me or is my point just not as obvious as I believed it to be? Edit: Not sure if that last bit sounds confrontational, please know that it's a genuine question.

So we've gone down a bit of a path here, and thats cool :-)

Thank you for taking the time to respond and ask. My original 418 message was very much intended as a light hearted joke, in the spirit of "if we wanted to return cheeky responses to previously nonsense APIs that AI invented" I actually like this idea of subverting AI in inventive ways.

Now to the point where we've got here, yes I 100% agree in real-world, production applications, you should return response codes which accurately represent the actual response. But there also a place for fun, even in production, and 418 represents that for me.

Thanks for caring about quality :-)

Re: Gaslight-driven development

#112

Post by eggn00dles » Fri, Jul 18, 2025, 2:43 AM UTC

pas wrote: post #94

eggn00dles wrote: post #34

Earlier quoted context omitted.

put implies overwriting instead of updating. upsert is for you insert/update.

update already means overwriting. semantically PUT is exactly upsert. upsert is update + create if not exists, which is exactly PUT any update without overwrite is "append" or "extend" (or something else)

append or extend is adding keys without updating existing keys. update can add keys and update existing keys.

put will blow away existing keys if they dont exist in the new payload. which is why it cant be upsert.

Re: Gaslight-driven development

#113

Post by pas » Fri, Jul 18, 2025, 1:11 PM UTC

eggn00dles wrote: post #112

pas wrote: post #94

Earlier quoted context omitted.

update already means overwriting. semantically PUT is exactly upsert. upsert is update + create if not exists, which is exactly PUT any update without overwrite is "append" or "extend" (or something else)

append or extend is adding keys without updating existing keys. update can add keys and update existing keys. put will blow away existing keys if they dont exist in the new payload. which is why it cant be upsert.

... it depends on how the given server defines PUT of course (also how we define upsert, and does upsert make sense outside a DB setting? well, of course some DBs have a HTTP/ReST API.)

that said, usually PUT is meaningful for a URL (or URI), and in these circumstances it's like upsert, and it cannot blow away other keys, as it operates on one key, given by the URL

of course if we assume a batch endpoint, sure, it then can do non-upsert-like things