Ironically - he doesn't it's kind of the whole flaw in the series.
How is JavaScript a minefield? Well, JavaScript has all sorts of pitfalls lurking for the developer. Each pitfall is like a mine in the minefield, silently waiting for you to accidentally step on it. Just like the minefield, JavaScript’s mines are hidden in plain sight. Entire books have been written about all the mines present in JavaScript. Maybe I’ll get into what some of those are in future blog posts.
So then he goes into why Typescript/Coffeescript/Dart aren't the answer to the "Javascript minefield" though he doesn't actually describe the mine's he's trying to avoid. He's not even bothering to setup a strawman to knock down. Its kind of hard for any tool to solve an undefined problem.
Given that a safe path through the JavaScript minefield isn’t enough, it seems like we need a detailed map of the minefield. Many books and blogs have been written to provide that map. JavaScript: The Definitive Guide by David Flanagan is one of the most detailed of those books. The JavaScript Garden is a good place to start learning about the mines online. [2]
Depends on whether or not quality of the product is a factor in your cost calculations. It should be, and for many startups and solo developers, it absolutely is.
> You have 0 control over distribution though, which is pretty important to me.
Simply having to wait a week to get approved for the iOS App Store (and less on Android) doesn't constitute 0 control over distribution. You can still release the app to the store when you want, if you plan ahead, and pull it whenever you like. Less control, yes, but not zero.
Also, how is this different from writing a non-native app? The same rules apply to distributing web apps if you want them to be in the store. True that you can release it as a website whenever you want, but that's not really the same thing.
> Simply having to wait a week to get approved for the iOS App Store (and less on Android) doesn't constitute 0 control over distribution. You can still release the app to the store when you want, if you plan ahead, and pull it whenever you like. Less control, yes, but not zero.
You don't have control whether your app will be accepted into the store (like the recent bitcoin apps), you don't have control whether the content in your app will be allowed in the store (such as the many Comixology comics that where banned from being sold).
> Also, how is this different from writing a non-native app? The same rules apply to distributing web apps if you want them to be in the store.
But I don't have to put my web apps in the store at all, I just tell my users to visit a URL.
I agree that you must put in time to get better, but I think the difference with programming is that more hours does not necessarily result in getting better. Actually, now that I think about it, maybe that's no different than the examples you provided. If you practice violin 14 hours a day, will you really be better than you would if you practiced 8 hours a day and spent the other 6 doing other things?
When programmers get beyond a critical daily/weekly threshold, putting in more hours hurts more than it helps. The brain gets tired of solving problems, and when that happens, pushing yourself further is not the answer. The answer is to do something else, especially something involving physical activity, to allow your brain time to recover.
I believe that many programmers fundamentally do not understand this concept, thus they drive themselves crazy trying to push harder and harder. Yes, you may write more lines of code that way, but at what cost?
No, they are crazy. Reverting someone else's changes without explaining why is crazy. No one is telling these people they can't explain their actions.
If any of these people has a disagreement with a co-worker over the co-worker's changes, it's their duty as a fellow employee to explain to the co-worker why they disagree, or at least explain to the manager why they disagree with the change, so that the manager can explain it to the co-worker. But just making the change and then threatening to quit... that is most definitely crazy.
Just want to clarify that my response here is not related to the GitHub story. I have no knowledge of the circumstances that aren't in the story.
> No, they are crazy.
That may be.
> Reverting someone else's changes without explaining why is crazy.
Not necessarily. There are times when you are so wrong you aren't even wrong.
> If any of these people has a disagreement with a co-worker over the co-worker's changes, it's their duty as a fellow employee to explain to the co-worker why they disagree, or at least explain to the manager why they disagree with the change, so that the manager can explain it to the co-worker.
Let's imagine a scenario where they had done this, and yet nothing had corrected the problem. At that point, it would be quite reasonable to revert someone's changes without explaining why, and threatening to quit if one wasn't allowed to.
> If you are so wrong you aren't even wrong, there are bigger problems at play and you probably shouldn't be working in that position in the first place.
Which is precisely why it would be eminently reasonable to quit, and therefore reasonable to threaten to quit.
> But in that scenario, whether or not you quit should not be contingent upon whether or not the change is kept, it should be whether or not you have to continue to work with that person.
Right, but anything less than reverting the change means you have to put up with the person, which again... is why one might threaten to quit.
I'm not sure surprised is the word I'd use to describe their sentiment. I'd guess rather that they originally planned to back down at the first sign of legal threats. Popcorn Time has been circulated as an experiment, not a business, and in that sense it was a success. Also, the code isn't going anywhere, so it's not as if all this work was for nothing.
Yes, and the fact that the state lies within a country now notorious for having a dysfunctional Congress, the same body that pulled the rug out from under SSC's original proposal in the 90s.
Is it possible that this bug was deliberately planted? Sure. Is it equally likely that this bug was deliberately planted as it is that the bug was a mistake? I say no, Occam's razor being the main reason for making that distinction.
https://hackertimes.com/item?id=7526619