I think the article summarizes pretty well what the drawbacks of POST are: unclear idempotency (well it's actually pretty damned clear: they are not cacheable). That complicates caching logic, and that's not just for the application server itself, but any reverse proxies in front of it as well as the user agent itself.
I'm not sure QUERY is a great solution, because in the context of a web application absolutely no one enjoys using a page that does not keep its state on refresh, so that really limits where QUERY makes sense, but if you have a case that is not driven by navigation, great.
Yeah its definitely inconsistent level of specificity. It's "roughly" 197 thousand files, and yet at that scale a human would call it 200 thousand lines of code, and then an exact count of files at 1,816 instead of a similar level of estimation.
For instance I might write this "The pull request alone adds nearly 200 thousand lines of code spanning almost two thousand files", or even better just "The pull request alone adds nearly 200 thousand lines of code" because really who cares how those are broken up into files.
As a human (as far as I know...) there is a decent chance I'd write it like that, depending on the exact numbers.
It said "over 197 thousand". That's what I'd probably say for a number in [197000, 197999], or maybe "under 198 thousand depending on where it is in that range.
Saying "nearly 200 thousand" is still 3 digits so doesn't save any space over 197 or 198, and I think with it only being 3 digits most people will assume only the last digit is rounded. 200 ending in a string of 0s does suggest it might be rounded to the nearest 10 or nearest 100, but it just could easily not be.
I'd almost certainly fully write out 1816. If it were common to spell out groups below 1000 like 100s and were going to that I might write it as something like "just over 18 hundred" or "almost 19 hundred", but I almost never see anyone use grouping sizes of less than 1000.
While I agree with your assessment, these data centers cause substantial noise and water pollution-- even if people didn't have a problem with AI the data centers would be a problem for people.
Yeah, that's the Linus "hard R" (he thought "hard R" referred to "retard"), but it's just wrong. "Hard R" is "nigger", in opposition to soft r ("nigga"). I don't think there's even a question, that's how hard/soft has always been used. Anything else is just confusion, I think.
Once you are squarely in a Typescript program and not a "Javascript program gradually adopting Typescript", it would be a good idea to enable Strict mode which forbids implicit-any, effectively meaning the only places you can omit type declarations is where the language will infer the type. Typescript for instance does not infer types of function arguments via their usages (like Flow does), which means in strict mode you must explicitly provide a type for all arguments within a function declaration.
I used to be a bit of a pragmatist when it comes to strict mode, but over the years that has subsided, nowadays I think it is plainly obvious that all Typescript programs should use strict mode unless there's a damn good reason. And I'm not sure there are any legitimate damn good reasons.
True there is no ability to forbid an explicit-any type declaration, though.
Are you sure about that? Creators aren't too excited about all of their content being hoovered up and used without compensation or permission, or the AI industry manufacturing economic pressure that devalues quality and the skills they've developed for a craft they are passionate about.
reply