Hadn't seen the union approach in #2 before, I like that a lot. The 2 named properties are intuitive to other developers reading it, but now we also get compile-time safety that the combinations they use are valid. Thanks!
1 + "2" (12) does a string concatenation.
1 - "2" (-1) does math.
That said, whilst JS is loosely typed and won't fall over when you do this, I'd just see it as bad form to find code mixing types to this extent. Just because the language will let you do it, doesn't mean you should actually do it!
To be fair, the + issue is a mistake many other languages have made too. Incredibly, PHP, poster child of bad languages, gets this right and splits + and . (though this may just be because it copied Perl).
It's fine to have a (string) + (string) operator, it's just generally a less than brilliant idea to have a (string) + (arbitrary) operator that does an implicit string conversion.
But all of that's fine compared to PHP's implicit number conversion that ignores trailing characters, presumably so that you can add "3 onions" to "1 kg of bacon" or some such...
I don't know your specific metrics, but one way to consider it is to forget about money for a minute. If you were to use one of those metrics to judge how successful your users were, which would it be?
Intercom.io is a brilliant example of this. They could have priced a million different ways, but they chose to charge by active users on their customer's apps. Now I don't even care about the price, I'll be happy to be doing so well each time I go up one of their price bands!
"We think getting your whole team on Intercom is a good thing. And we think talking to your customers is a good thing too. So we won’t tax you for either. We charge you more as your user base grows. Our interests are aligned."
Given the histories of these 2 writers, I'd have hoped for a bit more substance in such an important post for them.
They don't mention anything specific about the new site, and given how many other good tech sites there are, the vagueness doesn't make me curious enough to come back.
And in terms of journalistic integrity with full disclosures; I learnt more about what has really happened from the comments here than I did in that post. Surely they should have disclosed that a need to "refresh, reimagine, remake and reinvent" wasn't the only thing in play here.
It's worth considering how poorly handled the communications were here. No blog posts, no responses to the forum thread that mostly started all of this [1], nor the story that hit HN's front page [2].
Just Twitter. Which is something, but not enough when you have a PR issue this big...
I just don't store credit card details in my browser. Auto-complete for emails is extremely handy and I use that all the time, but does purchasing things online really need to be any easier?
I don't mind reaching for my wallet there; it forces you to make a conscious decision to spend the money, which is at least slightly better than a 1-click impulse.
Credit card details are not the main concern here (because they are separated on Chrome), but you could send your address and phone number to a server without expecting to send more than your name or email address.
True and it takes what? 1 minute of typing? Do we really need to go faster than that? Of course, companies are all in favour, but it's not in our interest.
Surely there was a better way to handle this? 1.1 million users in 8 hours on an un-official version? That's brilliant enthusiasm, which Blackberry don't often get these days. Simply shutting that down and telling them to register for some email updates is a bit of a dampener.
Couldn't they have become some massive trial group etc.? A giant set of early adopters to keep rolling out improved versions too (All with a big "alpha" caveat if that's what it takes), that can get people not yet in the group excited.
I think the little bit of hype and excitement from interested users is just the sort of thing BlackBerry needs, and putting a plug on that is crazy.
For anyone else that this was new to, Flow has documented these as "disjoint unions": https://flow.org/en/docs/types/unions/#toc-disjoint-unions