exo128's comments

exo128 · on May 19, 2020

Something like this should work:

  function allSettled(promises) {
      let settled = promises.map(p => p.then(
          v => ({status: 'fulfilled', value: v}),
          r => ({status: 'rejected', reason: r})
      ));
      return Promise.all(settled);
  }
  
  let p1 = Promise.resolve('foo');
  let p2 = Promise.resolve('bar');
  let p3 = Promise.resolve('baz');
  allSettled([p1, p2, p3]).then(console.log);
  
  let p4 = Promise.reject('err1');
  let p5 = Promise.resolve('bar');
  let p6 = Promise.reject('err3');
  allSettled([p4, p5, p6]).then(console.log);

exo128 · on Sept 12, 2017

It took me a bit to dig through the fringe cases to find the combination (or maybe an additional combination?) to pull that off.

x = ''

y = '-Infinity'

z = -1

x < y // true: '-Infinity' (y) doesn't get coerced into a number, so '' < 'any string with at least 1 character'

y < z // true: '-Infinity' (y) compares with a number, so it coerces to -Infinity, which is less than -1 (z)

z < x // true: '' (x) is compared with a number, so it coerces to 0, which is greater than -1 (z)

Thank you for the brain exercise!

P.S. - No one ever use crap like this in production code!

justinpombrio · on Sept 15, 2017

Oh interesting. The triple I found used the same general idea of values that sometimes coerce to a number, but it made use of octal values instead of Infinity.

exo128 · on Aug 25, 2017

Going further with the toolbox analogy...

Imagine we have carpenters and brick layers. Two distinct jobs that maybe have some overlap of tools.

We decide that we have a lot more carpenters than brick layers, so we'll take a carpenters' toolbox and add a few brick layer inspired tools to it (but they're not necessarily the same, and some of the tools that can overlap maybe aren't quite as specialized, nuances, nuances, etc.).

Now, we can tell our managers that our problems are solved. All of our carpenters can now do masonry work.

The root problem of all of this mess is that both of these domains are different. Problems and solutions in the front-end tend to be different than in the back-end.

Management is sold on this "everyone is an interchangeable cog now" fantasy they have been chasing for decades and crappy decisions are made. We end up with most developers not really learning at least one of the areas of the full stack very well (and not learning both if they are really striving to under-achieve...).

Note: This same thing happened in Java before NodeJS, but in reverse. Back-end developers refused to really learn web development and so we ended up with misguided solutions like GWT and virtually every other high level Java web framework/library.

Perhaps I haven't run into the right people, but mostly my experience with other JavaScript devs is they don't even know the fundamentals really (they don't understand scope rules in JS, they don't really understand weak typing, they don't understand JS is single threaded, they don't understand closures very well, etc.). I don't know if this lack of understanding is due to a lack of experience programming at all, or just not really learning JavaScript (many non-JS devs are forced to learn enough JS to get the front-end working -- or at least seemingly working).

The thought of lowering the bar on development even further is frightening (Johnny did some web development last year, I'm sure he can transition to writing our back-end API since he knows JS). I'm all for anyone learning and improving as a developer -- and sharing in my passion. What I hate is this false confidence more and more people seem to have with everything and the problems it causes (they don't bother to learn the tools they have or the tools that came before them, they are too lazy to learn a new language/framework/library, and they have extreme NIH syndrome).

exo128 · on Feb 3, 2017

"giving more money to ... will increase inequality."

You're defining "income inequality" as only in relation to the median or average income. That is too simple to make any sense. By that model, I could have 1000 people making $1/hr, 10 people making $10/hr, and 1 person making $2000/hr. This puts the average at $3/hr. And so you say protecting the $10/hr people's salaries from being artificially suppressed increases income inequality because you've arbitrarily defined the line at the average income.

Also, you're ignoring where the money is coming from, so any math in your mental model is flawed. I would hope this discussion isn't about creating money and giving it to >$100k/year engineers, but rather the business owners with capital paying market rates instead of having a way to suppress skilled labor salaries by exploiting weaker economies and tethering foreign employees for upwards of 9 years before they can finally correct their salary and working conditions (hint: I've worked with a few people who have been exploited like this).

This whole us-vs-them scam of pitting everyone in the middle and lower class against themselves that the media/business/etc. has been doing (probably for longer than I've been alive) is amazingly effective...

Most people want and value many of the same things and greatly outnumber our overlords, but somehow we're always pointing the finger at each other ("you're just lazy", "you're just racist", "a true <blank> would/wouldn't <blank>", "check your privilege", etc.). And all the while, the powers that be siphon away money and power and continue to set the stage in their favor.