vmasto
Womb.FM - https://www.womb.fm
When using an open source library assumptions should be:
- The code does what it advertises.
- The owner is responsible for the functionality.
- The owner's reputation is based on the quality.
You're making it sound that you're more sure for the above when the code is "hand-written" than LLM-driven. Why exactly? Do you tend to deeply understand the strengths and limitations of every coder whose software you're using in your projects?
As long as the owner is responsible for the quality of a project why does it matter how it was executed?
Stress is a silent killer. It's basically being mostly unhappy, feeling unfulfilled and trapped. It's a spectrum that can range from simply being unhappy to being deeply depressed.
Still, If we want to be pedantic and literal (i.e. assume I'm talking about the Marxist definition) it still holds true, as class is not defined by compensation but by the role of the individual within the production process.
What makes you think that whatever is wrong with Reddit is due to lack of talent? It almost never is.
I'm not sure why you were disappointed, editorconfig does not advertise the features you mentioned. For more involved autoformatting you need some kind of tool like gofmt or Prettier for JavaScript.
For what it's worth the url and the author's handle threw me off. "harthrur", simply thought of someone named Arthur in their first name, not the last. I completely ignored the website's name as well it seems.
Not meaning to be condescending, that's not how probability works or is expressed.
Also, the fact that the ocean "is a large place" says nothing about how probable or not the events to create and sustain life are.
I understand most people have this gut feeling that because the universe is vast and ancient there must be something out there (and I have it too), but we just don't know.
We just have no idea exactly how hard life is to develop and be sustained. We just started having theories (a handful at that) about how we transcended from chemistry to biology. The prevalent theory for example is that the moon's unusually big size and proximity was the catalyst for that to happen. How many planets have extremely big moons in such close proximity? How many million other factors played a role assuming the tide theory is even close to accurate?
It's just an infinitely complex problem and we just don't know.
I'm running infinite scroll in production serving thousands of photos and it works pretty well, constant 60fps, low memory consumption and you could literally scroll infinitely (given infinite content).
An AI doesn't need to do this.
Source: Ex pro Starcraft (Brood War) gamer.
I haven't found a use case where it would be necessary, and when it would seem it is, it's indicatory of code smell, e.g. badly formatted JSON responses.
Maybe a use case for abstract equality could be for comparing HTML data attributes (which all return strings by default using the web APIs). In this case it would be far better to abstract your HTML data attr wrapper to something like jQuery's .data method which will always return correct specific types rather than strings (e.g. data-bool="true" will return _true_ (bool) instead of "true" (string)). I believe many of JavaScript's old quirks are due to trying to interoperate with HTML better.
> In most cases if (!foo) is what you are interested in and it's cleaner.
In most cases yes, but there are cases where you simply want to check explicitly for undefined or null (e.g. does a variable or property exist or has a value, even if it's an empty string or 0). !foo means your variable isn't: an empty string, the number 0, the bool false, null or undefined.
It's also worth noting that `===` is not deep equality. It's merely referential equality (the equivalent of .is in other languages) for all non-primitive types.
e.g. [1,2,3] === [1,2,3] will always return false since the two arrays are different objects and point to different references. "123" === "123" will return true because they are both Strings (considered primitive types in JS).
Abstract equality will always fallback to strict equality when the types of the compared values are the same, but using strict equality everywhere avoids headaches that might come up during runtime.
Edit: I'm not sure why you're being downvoted, you're simply asking a question.
There's absolutely 0 benefit from an engineering standpoint in having type coercion memorized in JavaScript.
I'd personally immediately terminate every interview that posed such questions ({} + [] + '' or whatever).
I mean no offense, but I'd ask you to reconsider. People who ask trick/puzzle questions and hacks in interviews do not understand (or haven't thought deeply enough) how to properly screen JS developers which eventually goes through to the team itself. There are at least a dozen more interesting topics to question on if you want to assign extra points than useless stuff that should never be into production in the first place.
No, do not consider these examples as a "great" resource for interview questions. They are nothing more than tricks and hacks abusing the bad aspects of the language and anyone who includes them in an interview has failed in screening JavaScript developers, at least in my book.
A JS developer should understand that JavaScript has some flawed, unfixable core concepts and educate themselves on how to avoid them, not use them in actual production code or memorize every coercion scenario.
Some simple rules:
1. Always use referential equality checks (triple equal `===`). In idiomatic JS you can also use double equality only when explicitly checking against undefined or null (foo == null). It's the only use of abstract equality that I find acceptable.
2. Learn how the `this` execution context works. Kyle Simpson explains it very well in YDKJS (https://github.com/getify/You-Dont-Know-JS/blob/master/this%...). There are four simple rules that matter and are straightforward to grasp.
3. Familiarize yourself with how type coercion works in JS but avoid it. The spec is quite easy to follow in this matter and follows very specific, documented rules. e.g.:
https://www.ecma-international.org/ecma-262/8.0/index.html#s... https://www.ecma-international.org/ecma-262/8.0/index.html#s...
Use strictly as reference.
4. Stop using plain ES5, the language currently is ES2017. ES2015 and beyond provide modern constructs that make most of ES5's weirdness obsolete. For example, never use `var` anymore, `const` and `let` are superior initializers.
By following the above rules a JS developer should be fine in 99% of cases, in my experience. Yes, JavaScript will possibly implode on you on the rest 1%, but I'd be hard pressed to find a (similarly popular) language that doesn't. If one finds that to be unacceptable, enabling types via TypeScript or Flow should make their life even easier.
five.asPromised?