Kwantuum

The fact that this can happen at all without the security team's knowledge is telling.

I trust openAI's marketing team 100%

Interestingly, in the company I currently work for, if an employee encounters a problem with the product, the expected way to report the issue is to open a ticket. Not in an different system with different people responsible for handling it, in the same ticketing system that customers use.

Hackintosh refers to doing things the other way around: running MacOS on non-apple hardware. So no, this is not a hackintosh.

Both of the things you quoted are basically gone in practice, you just always use const/let and always use triple-equals for equality comparisons and that's that. Most people that write JavaScript regularly will lint these out in the first place.

OTOH I think JS has great ergonomics especially wrt closures which a number of popular languages get wrong. Arrow functions provide a syntactically pleasant way to write lambdas, let/const having per iteration binding in loops to avoid nasty surprises when capturing variables, and a good number of standard methods that exploit them (eg map/filter on arrays). I also think, though a lot of people would disagree because of function coloring, that built-in async is a great boon for a scripting languages, you can do long operations like IO without having to worry about threading or locking up a thread, so you get to work with a single threaded mental model with a good few sharp edges removed.

I've had to stop using FF as my development browser because it chokes on large source maps. I used to find lots of issues in our web app that were only ever tested on chromium browsers. I don't anymore because the devtools are unusable past a certain point.

I guess you can attach a debugger for unit tests, but that's not very useful.

That is in fact incredibly useful

Surely this was meant to be cnt += a[i] > 0

The most egregious problem caused by this that I've encountered is an almost complete inability to use email 2FA on websites because my phone will kill the browser as soon as I switch to my inbox, and when I go back to the browser I'm back on the login screen which will generate a new one-time-password and make the one I have in my clipboard worthless. I've also encountered the exact same problem with 2FA using an authenticator app, though since the codes are valid for ~30 seconds or so, if I manage to enter my credentials fast enough or they auto-fill, at least the code I copied is still valid.

There are several points in the article which are just plain wrong:

- no private properties (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)

- no readonly properties: You can use a getter. Or define the property as non-writable, the syntax isn't nice but in my opinion it's still much nicer than what the article proposes.

Some of the points are just a matter of taste ("this" is awkward)

There's the implementation itself which forces you to use non-idiomatic code for no good reason or benefit (Class.init instead of new, just why? You can absolutely return a constructor function there while preserving everything else)

Doing what the article proposes also destroys the ability to do instanceof checks because the prototype of instances is not set (can be fixed), and inheritance is severely limited if you want to preserve any of the purported benefits. You might say that inheritance is actually not a good thing and so it's a feature, not a bug, but if that's your opinion why are you trying to mimic a class?

There was not. There is now but for the better part of a decade it was just... Something you were supposed to have learned from a youtube video or a friend or something.

Pretty sure they're just replying specifically to

you still have guilty parties going free anyways since the wrong person is convicted

which is a non sequitur.

Now you impose sanctions in your jurisdiction to violators and nobody cares because you're not the EU and your sanctions have no weight.

A lot of the comments seem to talk about the inevitable AI event horizon but unless I'm misreading this article the results are flat out bad. Even the 6 billion parameters model barely scratches a 50% success rate on a tiny problem that is trivial to fix for any human with basic knowledge of programming. Note the log scale of the graph.

(damnit, of course calculating the permutations of a list is n-squared, but this is an interrogation of the random trivia I can manage to recall and I feel like a deer in the headlights)

With this statement I'm inclined to believe the title. Last I checked there are (n-1)! permutations for a list of length n. Not knowing this off the top of your head is fine, but making this kind of comment is an unforced error and it doesn't reflect well on the author.

Website is completely broken in firefox when javascript is enabled.

You are missing the point completely.

The IKEA effect is not "self assembly", the IKEA effect is "I think of this piece of furniture more highly because I assembled it myself". The IKEA effect compares how people feel about the same piece of furniture when they've assembled it themselves vs when someone else did it.

That's a lot of words to say "to make fraud harder you have to make buying from you harder, the optimal amount of fraud is the amount of fraud you get when any additional measure you could take against fraud would lower your revenue more from lost business than it would lower your costs from people committing less fraud"

from the linked PTC proposal in the article (https://github.com/tc39/proposal-ptc-syntax):

Unfortunately, the TC39 process at this time did not require heavy implementation involvement and so while many implementers were skeptical, the feature was included and standardized as part of ES6.

the type of fetch() can't be inferred by static analysis

That is preposterous.

It really isn't, most native/standard APIs do not return Promises. Lots of things use callbacks. Being comfortable creating Promises from a callback-based API is definitely something any competent JS dev ought to be able to do.

The original article doesn't just suggest it, it claims it outright, and links a study to back up that claim: https://www.annallergy.org/article/S1081-1206(10)60240-2/ful...

And in fact, there were detours in pretty much all the solutions I've seen posted online for part 2

The earth has "holes" and as such the proof of that statement for a sphere does not apply to the earth.

I can see this being useful when you're maintaining multiple versions and forward-porting patches. Some patches only make sense up to a certain version and you don't want to merge them in the next one up.

It's not just "some" caveats: then auto-unwrapping means that you cannot use then as fmap reliably. In JS there is no such thing as Promise<Promise<Number>>. You cannot await/then the outer promise so that you can do something with the inner promise.

In practice it's not too much of a problem, but it does mean that if you use some FP library, you cannot trivially wrap a promise to make it a monadic type that will work with the library's monad utilities.

Your id does not contained a cryptographically signed vaccination status, which this is.

console.dir does the same thing as console.log in every modern browser. I'm tired of seeing this "tip", and it's a pretty clear indication the article is poorly researched, the only difference is that it pre-expands the object.

The thing is, if you have any sort of front-end that is not entirely server-side rendered, you're going to have to work in JS at least some of the time. If your back-end is also in JS, you now get the benefit of isomorphic code for things that you may want to do on both front-end and back-end.

Then there is also the fact that JS is actually a pretty great language if you know how to avoid the footguns. Granted that's not always easy, but it's a language with lexical closures and easy and familiar syntax, it's also very expressive and has a vast ecosystem supporting it. And you can even add the typescript compiler on top if you want compile-time type-checking.

It's also async out of the box, and while that doesn't solve all problems, it scales surprisingly well with no performance tuning whatsoever, it even has decent asynchronous primitives that make it easier to write correct code.

That repo is interesting. A quick ctrl+F seems to indicate that pretty much every instance of "MongoDB" is "Moving from Mongo to Postrges or DynamoDB" (there is one single entry of moving to Mongo from MySQL). Almost as if Mongo is just not a good database (or people are too eager to use it for things which it does not do well).