429 karma · joined April 20, 2017
>that make SWIFT innovations seem trivial by comparison
Listen, those two phrases alone are gigantic signs of your bias. Even if they were true, the way you phrase it just screams "I own a significant amount of Bitcoin"
Add to that a sentence about
>a whole host of breathtakingly innovative developments
and, oh boy, do I ever think you are biased.
There is actually a pretty clear value prop for Bitcoin: you can exchange something approximating money for services which are undesirable or risky to do so with your traditional money. But needing to build an entirely new layer which, if I'm understanding right, has some significant impact on the semantics of how your transactions end up on the blockchain, just in order to be able to do a completely unimpressive level of throughput, is hilariously far from "breathtaking innovation" that makes traditional financial "innovations seem trivial".
It's an interpolation thing; it's much easier for your brain to do the tracking of an object when it smoothly moves around, instead of it having to do interp / extrapolation, and this should demonstrate why
Can I ask why you think it sounds like a placebo? I don't really see why there's any logic behind 144hz being the ceiling of how well your eyes can see, and 144hz -> 240hz is a big jump
That's why it must really say something about these companies - Verizon especially - that them voluntarily stopping such a practice makes me imagine they have nefarious motives in mind.
Either that, or they just think net neutrality's death is going to be so much more profitable than this that it's not worth the man-hours anymore.
Right, and Steam has a 100% marketshare in the distribution of apps available on Steam.
Now, obviously there's wrinkles here and I'm not trying to be disingenuous and claim that these are identical scenarios. But you see how this quickly gets subtle, yes?
Alas.
>Acrylamide is known to cause cancer
>Coffee apparently contains (significant) amounts of acrylamide
The first thing I come across, as usual, is Wikipedia [1]. The summary says:
>As of 2018 it is still not clear whether acrylamide consumption affects people's risk of developing cancer.
It provides two sources [2][3], from the Cancer Research UK and the US National Cancer Institute. The abstract of [2] implies that animal studies show some interaction with DNA, but fairly conclusively says:
>[E]vidence from human studies has shown that, for most cancer types, there is no link between acrylamide and cancer risk. Some studies have suggested a higher risk of womb cancer, but the evidence is weak and inconsistent, so we can’t be sure if this link is real.
The other source [3] is a bit of a more informal FAQ style, and poses the question "Is there an association between acrylamide and cancer?" Again, I see the implication of animal studies possibly showing real links between cancer and the substance, yet
>a large number of epidemiologic studies (both case-control and cohort studies) in humans have found no consistent evidence that dietary acrylamide exposure is associated with the risk of any type of cancer
Can you explain your comment, and especially the last sentence you provide? My search was extremely cursory, but I would be fairly confident that if it's too strong a claim to say this substance doesn't cause cancer, I could at least conclude that saying
>[T]he state is proposing a rule contrary to its own scientific conclusion
is patently false.
Sources:
[1]: https://en.wikipedia.org/wiki/Acrylamide
[2]: http://www.cancerresearchuk.org/about-cancer/causes-of-cance...
[3]: https://www.cancer.gov/about-cancer/causes-prevention/risk/d...
It was an ad hominem and I asked him to expound on it.
From everything I've seen, its performance sits just below Java (4x slower, perhaps) on some standard algorithms or tasks, and significantly faster than languages like Ruby, Python, etc.. I never see hate for those languages like for JS, so I'll disregard that.
>not terribly good
This one never has made sense. What is it missing that makes you hate it so? I think it has rather robust asynchronous handling, 'everything is an object' has lots of nice implications when paired with functionality like Object.keys / .assign, ... So what are the issues you see that make it 'bad'?
Can you give a simple analysis on what weaknesses JS has that other languages would avoid with no pitfalls of their own?
What's wrong with JS, exactly, that isn't made up for by its advantages?
I see these 'kool-aid' / 'JS is cancer' comments all the time, but they don't come with any real details.
I feel like you've probably never really used JS, if I'm being honest.
At this point, I'm not even sure if a single comment in this thread that poses itself as obviously anti-JS has a valid knock on the language, just high-level, hand-wavy reasoning about why it is so poor.
Of course, but I hardly see how that's comparable to writing a React class "ToolTip" which is smart enough to know where the side of the screen is, and comes with the ability to use JS.
I see this being said, but from what I've seen async handling is generally not very graceful; with that said, Promises are a very simple but powerful API that seem to handle the problem fairly elegantly.
That is why I'm surprised. I just don't know what the alternative is supposed to be! Can you point me to a language and a library that you would say does a better job of handling asynchronicity than Promises?
This way, you write the API request to just be a simple function invocation of the class you instantiated:
(req, res, next) => {
apiHandler = new APIHandler(args);
apiHandler.saveData(req.body)
.then(
// success
() => res.status(200).json(apiHandler.getResponse()),
// error
() => res.status(400|500).json(apiHandler.getErrorResponse())
)
I mean, it's just a pattern, and I wouldn't necessarily say I use it all the time; it's especially valuable for workers, where you have a series of functions you want to execute where some of them are going to be asynchronous.If you're just making simple create / update / get requests, it's less valuable, and you can just return a Promise from somewhere. Hopefully that gave you an idea of my motivations
I work a lot with databases, so say you're trying to write an object and its children in some sort of one-to-many relationship to the DB.
You can write a Promise chain like
startTransaction()
.then(() => writeParent())
.then((children) =>
Promise.all(children.map((child) =>
writeChild(child)
))
)
.then(
// handle success
endTransaction(),
// handle error
cancelTransaction()
)
What exactly about that isn't "proper error handling"? Can you expand a bit on how this would be handled differently by you, or perhaps what paradigm you're programming in where Promise.all executes a bunch of items that can't all have the same success and error handler?A few years later, I use Promises a lot, and they work really well. The way errors bubble is logical and easily controlled, it's almost impossible to throw an unhandled promise exception, doing 'parallel' tasks is easy with ```Promise.all([])```, and there's pretty limited complexity with the way a Promise always returns a Promise.
I find the simplest way to use them is to define a class that has a few data properties you'd like to track.
class Handler {
constructor() {
// shared variables can be set / reset here
this.defineInitialState();
}
executeAction() {
return (
this.promiseFn()
.then(() => this.anotherPromise())
.then((passedArgument) => this.promiseExpectingArgument())
.then(
// success case
() => this.successHandler(),
(err) => this.errorHandler()
)
);
}
}
It's modular and you know what to expect (it's always a promise!). Sure, it's imperfect, but I think its weakly opinionated simplicity is a good tradeoff. After all, it makes no distinction of whether any of the functions in that chain were synchronous or not, and that's a nice thing to know. It also makes testing with dummy sync functions in place of actually asynchronous ones a 0-effort integration.I don't know about this async / await keyword stuff, and if you have to wrap it in a try/catch block, that's unfortunate but also seems like it's not the end of the world. After all, isn't the Go language constantly requiring you to say "if err != nil <your code>"? Explicit error handling isn't even a bad thing.
Anyways, this is just my opinion, it's fair to have your own, and maybe other languages handle asynchronicity more gracefully, but from what I've seen this is a clean way to wrap async OR sync code in a context that makes it always behave predictably and readably.
The real question, I thought, is: are losses per sale decreasing? If not, and if we need to see a significant price increase per ride before things can get better, I sort of wonder if the only thing the taxi industry needed to do to prevent this all from happening was develop a ride-hailing app which tracked your car and gave you the price ahead of time.
Ah yes, the calling card of people that think systematic exploitation of workers in a global economy where only the top few are gaining wealth is fine because "free market rules" matter in a world full of regulatory capture and industries with too high of a barrier to entry to foster true competition.
That said, it is best used as you describe it: a store that holds all the application state and manages API requests, and then any time it updates, any components observing this store will be forceUpdated