Well, this looks like the equivalent of GPTs to me. Meaning some user, in this case the user “sluttypuffin”, has chosen the prompt directives that instruct the model about how it should respond. So the hyperbolized nature of this is (and I’m guessing to be clear) is likely something that sluttypuffin specifically constructed with their prompt engineering.
This is where prompt engineering becomes more important. Next time consider pre-pending some kind of plain English set of expectations before pasting your code. Something like, “I want you to write tests for this code. Here are the expected behaviors <expected behaviors list>, and here are unexpected behaviors <unexpected behaviors list>. Tests should pass if they adhere to the expected behaviors and fail if they have unexpected behaviors. Here is the code: <code>”.
Like most LLM generation though, it’s not a deterministic thing and like you mentioned originally it takes some verification of the output. I still think with the extra steps it saves time when applied to the right scenarios. The longer the input the higher the hallucinations count in my experience though, so I always keep the code provided in the smallest chunk possible which still has enough context.
>cultural adoption reproducing itself
… what? You’ve gone to great lengths here to fabricate a phrase that is semantically equivalent to “influence” in the most obfuscated way possible.
>cultural hegemony
See previous … what?
Let’s get down to brass tax.
A does foo.
B notices A has done foo.
B decides it will also do foo.
A has influenced B.
There are other aspects about the original comment which were better targets than attacking the meaning of “influence”, such as America’s status as a melting pot whose traditions are in great part just the collection of influences from the multitude of ethnicities which can be represented by the single term “American”. Thinking America has such dramatic unique influence while ignoring its composition of influences from other cultures is not giving honest context. That’s the part I would have gone after.
I mean, they probably would if public services paid their engineers Google salaries. Do you think someone who can make 150k at Google is going to take a public services eng job for at minimum 50% less pay? Of course to have public service jobs like that we’d have to pay more taxes… and thus you end up with overworked engineers who are probably ok at their job but not on the same level as the big private companies
The things you seem to be worried about are configurable in the tsconfig. You can stay as polyfill free as you would like by instructing the Typescript compiler to error out instead of making the glue for you. Aside from the inescapable quirks of runtime JavaScript, Typescript felt pretty intuitive to me when transitioning to a new job from C# previously. Typescript with ESLint is about as solid as you’re going to get with JavaScript. I know that ideally there’d be something better, but in the real world right now this is the best it gets. At some point reality and business constraints are going to slam into ideations and things are going to get a bit dirty.
Aside from that, no matter what you pick, standard Typescript configs are absolutely compiling to JavaScript, not any other step in the interpreting process. It doesn’t matter if it’s taking your async/await and polyfilling it to run on an older browser engine… it’s still producing 100% JavaScript.
It goes Typescript -> JavaScript during the build, and the JS is what gets distributed to clients.
The JavaScript produced by TS is sent to the browser which performs the same JavaScript -> abstract syntax tree -> byte code -> execution, as usual
It’s also possible this commenter is seeing a fallback default font if Atpos is not available / didn’t download correctly on their system configuration