3 ms·
I am not entirely convinced that there is actually an inherent tension between runtime performance and being fast to learn, read and write. So it might just be
by chc 12y ago
I am not entirely convinced that there is actually an inherent tension between runtime performance and being fast to learn, read and write. So it might just be that Python is simply slow, and although it has a lot of nice features, the slowness doesn't really have much of an upside.
- deleted 12y ago[deleted]
- cessor 12y agoThere is no such tension inherently, yet I have seen a lot of violations of good practices in the name of "more performance". C# might be slower than C++, yes, but the question is: is it fast enough for what I would like to do? The fact that it is garbage collected and doesn't require pointer syntax makes it nicer to use, yet it runs slower. I have made similar experiences with databases, normalization is often discarded due to performance concerns (woohoo, too manz joins). It is true, making a join is slower than not making it, but the performance is gained by having less redundancy checks (I know, I am oversimplifying this). I am just very tired of seeing performance as an infinite target for optimization at the cost of maintainabilty, readability and so on. Exaggeratingly I could state: If you want it REALLY fast, write it in assembly. Do you see what I mean?
- cessor 12y agoAs a follow up on my opinion, here is another item that was recently on hn. Tj Hollowaychuck is leaving node for go, mentioning this discrepancy (runtime focus vs working with it time focus) as a reason https://news.ycombinator.com/item?id=7987146 https://news.ycombinator.com/item?id=7987146