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.
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.
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.
- 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.
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.
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"
> 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.