4 ms·
This is a very silly argument: compile and runtime speed is not the only consideration to take into account. Otherwise we would all be programming assembly, or
by wheelie_boy 8y ago
This is a very silly argument: compile and runtime speed is not the only consideration to take into account.
Otherwise we would all be programming assembly, or heck, just write machine code directly and skip the time-consuming assembler.
Speed is important, but so is good debugger support, productive UI tools, developer productivity, training requirements, available libraries, target market, etc. At the end of the day, most people make pragmatic decisions, taking lots of factors into account.
A good historical example of this is Word vs. WordPerfect. There are many reasons why Word won, but one of them is that WordPerfect was written in assembly. This was helpful at the beginning as it was good for performance, but their developer productivity suffered as the codebase increased. This resulted in fewer features, which is also something that customers care about.
Few customers care how quickly you can do something they don't want to do.
Also, he's conflating toy problems, where getting the big-O right is the only important thing, with real-world applications where the constants are also important.
- shhehebehdh 8y agoThe article is interesting food for thought, but there’s a fundamental error. In the toy algorithmic problems, having the wrong big O solution is wrong because it doesn’t finish in a satisfactory amount of time. From this he seems to infer that anything that takes longer than another alternative is “wrong.” But the thing that made the toy solution wrong does not transfer to the other example problems! An editor dropping frames clearly isn’t sufficient to render it unusable for a significant slice of the target audience (proof by existence).
- alexashka 8y agoReplace 'wrong' with 'sucks' and you'll be much closer to getting what the author's saying.
- redka 8y agoStill doesn't make the metaphor make any sense. If anything, it is proving the exact opposite point since when it comes to programing languages/environments the difference in speed is much more comparable to the 10-30ms from the example (negligible) than to the "years" - the one being "wrong".
- shhehebehdh 8y agoIf he meant that word, he should have used that word. Even if he meant “sucks,” I don’t think he’s right. I use VS Code professionally. It’s far better than Sublime Text or notepad++, despite making different trade offs on the native vs electron UI front. To say something sucks is a wholistic statements that isn’t supported by the evidence he gives. It’s far more accurate to say “it’s unfortunate that electron has these drawbacks.” That’s true but also kind of vacuous.
- UweSchmidt 8y agoGood points, but: A cross-platform UI framework could easily fulfill all your requirements, yet doesn't exist.
- wheelie_boy 8y agoI'm not saying that I have requirements, just that there are different considerations when choosing a tech stack other than compile/run speed. Several cross-platform UI frameworks do exist, all with different pros and cons. I don't think it would be possible for a single UI framework to override all other considerations when choosing a tech stack. It would have to be pretty magical.
- quickthrower2 8y agoEspecially compile speed, and especially if the program is composed of libraries that don’t all need to be compiled every time. There is something super nice about editing JS and being able to see the change immediately, but I’d still trade that off for some type safety in a “compile to JS” language that wastes a second of my time per compile. The other point about compile speed is it doesn’t affect the end user (if we are talking about source code compilation not JIT)