I agree with his basic premise that if a faster solution exists, it is better, and believe that considering how many users a relatively miniscule development team will impact warrants much more inconvenience on the developers’ part to make the users’ experience better–an extra couple of days for me vs. possible man-months of lost productivity in aggregate for my users.
Some of the truisms in the article rubbed me the wrong way though:
> It’s not that they couldn’t build faster. They just choose not to.
I’m not sure I agree and I don’t see what it’s adding to the argument.
> in the end what matters is if you have a working program on your hand and if it can produce the answer in a reasonable time. It doesn’t really matter how the developer arrived there.
Is this sarcasm? From my opening comments you’ll see I disagree with this. But, I originally thought the author did too.
Then they go on to construct an analogy of a shitty train and an awesome plane that cost the same. Where did they get this part from? I thought the reason people chose e.g. Electron vs. native is that there is a different cost involved for the developers?
> It’s easy to find excuses why things are the way they are. They are all probably valid, but they are excuses.
I used to assert the opposite when I was young, to my parents: “It’s not an excuse, it’s a reason.” It’s easy to dismiss others’ arguments out of hand, but the fact is there is a reason for every decision made, even if you disagree with the reasoning. There is always room for more education. I just don’t see how we can make any headway if we ignore each other like this. This reads to me more like “I don’t understand why C++ or Rust compile slower.”
> We know way faster programs are possible, and that makes everything else just plain wrong.
It’s easy to fall into the right vs. wrong argument when talking about programming–binary logic, tests either pass or fail. But we’re in the human realm here, where I’m of the opinion that there is no right or wrong, only consensus. In the case of products, like Slack, consensus manifests as what the market will bear. I might not agree, but for the time being, the industry has deemed it “right.”
Some of the truisms in the article rubbed me the wrong way though:
> It’s not that they couldn’t build faster. They just choose not to.
I’m not sure I agree and I don’t see what it’s adding to the argument.
> in the end what matters is if you have a working program on your hand and if it can produce the answer in a reasonable time. It doesn’t really matter how the developer arrived there.
Is this sarcasm? From my opening comments you’ll see I disagree with this. But, I originally thought the author did too.
Then they go on to construct an analogy of a shitty train and an awesome plane that cost the same. Where did they get this part from? I thought the reason people chose e.g. Electron vs. native is that there is a different cost involved for the developers?
> It’s easy to find excuses why things are the way they are. They are all probably valid, but they are excuses.
I used to assert the opposite when I was young, to my parents: “It’s not an excuse, it’s a reason.” It’s easy to dismiss others’ arguments out of hand, but the fact is there is a reason for every decision made, even if you disagree with the reasoning. There is always room for more education. I just don’t see how we can make any headway if we ignore each other like this. This reads to me more like “I don’t understand why C++ or Rust compile slower.”
> We know way faster programs are possible, and that makes everything else just plain wrong.
It’s easy to fall into the right vs. wrong argument when talking about programming–binary logic, tests either pass or fail. But we’re in the human realm here, where I’m of the opinion that there is no right or wrong, only consensus. In the case of products, like Slack, consensus manifests as what the market will bear. I might not agree, but for the time being, the industry has deemed it “right.”