Quick request, if it's doable: would you mind making a portable version of this? We're super locked down on our machines (even as developers), and all programs that need to be installed need to be approved. Portable programs fly under the radar, so they're easier to try discreetly, then we can make an official request to get them approved or buy a license.
Edit: oh my, you also made Insomnia, that I used when Postman was on the enshittification path...
AI image generation wasn't good enough in early 2022 to generate game assets. Yeah you could probably generate pokemon-like looking stuff, but it wouldn't be usable as-is in a game.
Edit: and even today. Generate textures for blocky assets? Sure. But full pokémon models that wouldn't need a ton of rework? Nope.
It's implied that GPT-4 has so many restrictions that will not argue and just do what is asked. In the context of the joke, an unfiltered LLM will just debate you.
I've been writing TypeScript for at least 6 years now, and I couldn't go back to JavaScript. I understand the arguments of those who don't like it, but ultimately they all boil down to either "writing types is tedious" or "I know better than the compiler".
> I spend more time trying to resolve TypeScript complaints than I do adding code
Those complaints from the compiler are the main feature of any statically typed language! In TypeScript, they're here to tell you that something is potentially wrong with your code, and it might break in runtime.
"I spend more time trying to resolve [typing errors] than I do adding code" is something you'll hear from anyone that is not used to statically typed languages. _Any_ language, not just TypeScript. And it's an issue that quickly goes away by itself once you learn the language.
> Our team has lost hours on TypeScript exceptions in staging and production builds (but oddly not offline/local) where some external type was missing or incompatible, another one being that the local environment passes linting but CI doesn't, it shouldn't be so hard
That one is probably a simple configuration issue, not TypeScript's fault.
> Having to rewrite correctly and infallible JavaScript so that it was friendly enough for TypeScript to understand
This one I can get behind, but I'd put it in the same bag as the first point. I'm sometimes tempted to use things like non-null assertions (like in the example with the .filter().map()) but I'd say that 99.9% of the time the compiler is right, and it's safer to right one more line than a `!`. But you don't do it to make TypeScript happy, you do it to rule out a potential edge case, and avoid a runtime crash.