3 ms·
I recently realized one aspect of why it is bad: https://docs.python.org/2/tutorial/ https://docs.python.org/2/tutorial/ is probably the first thing that pops
by cessor 12y ago
I recently realized one aspect of why it is bad:
https://docs.python.org/2/tutorial/ https://docs.python.org/2/tutorial/
is probably the first thing that pops up when you search of python and tutorial, yet it reads like it is adressed at people that are looking for a way to augment their unix shell. This is not very helpful to most people. Thankfully, there are many alternatives, however it is bad that this is the first thing that pops up.
I am confused by the why is "X so slow" argument. Conceptually and practically, Python might be slower than native C code, but the tradeof lies in the relationship between runtime and "design"-time. It is a little slower, but it is faster to learn, read and write. Demands for "more performance" should be driven by actual numbers: How many people should your webservice serve in a second, minute? So far python has been fast enough for anything I wanted to do. For everything else there is numpy/scipy - fortran for the win!
- chc 12y agoI 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