4 ms·
Why is it bizarre? His point is that the article shouldn't make it sound like "Python is fast", because the speed actually comes from the libraries that have b
by sukulaku 11y ago
Why is it bizarre?
His point is that the article shouldn't make it sound like "Python is fast", because the speed actually comes from the libraries that have been implemented in C.
- wesm 11y agoBy bizarre I mean impractical and unhelpful. What's the point of programming at all if we cannot leverage abstractions to make ourselves more productive? I believe what the article says is that "Python has tools that enable a savvy user to achieve better results with less effort". Python is extremely popular in HPC settings (including supercomputers) for this reason. I see nothing disingenuous.
- sukulaku 11y agoWell, the word "bizarre" has a commonly understood meaning, but you somehow decided to use it to mean something completely different. That's a bit bizarre :P But the article is titled: "Why I Still Use Python for High Performance Scientific Computing", and it gives the impression that Python - the language - is fast enough for HPSC. In reality, the reason why he "still" uses Python is that the libraries are fast enough for HPSC. But that's not what people see when reading posts like this. The message they see is that "Python is fast", not that some of its 3rd-party libraries are fast. But I should probably stop repeating myself here.
- andreasvc 11y agoFirst, there's no reason to only associate "Python" with "the language", it is an environment, ecosystem, etc. It's not interesting to narrowly focus on the efficiency of the interpreter. Second, it is an inherent feature of the design of CPython that its C API allows tight integration with external libraries in C. Cython does not just glue C and Python together, it does this in a way which makes the integration easier and safer than doing it by hand (e.g., generating correct reference counting code). All of this is a direct benefit of Python and its scientific ecosystem.
- sukulaku 11y ago> First, there's no reason to only associate "Python" with "the language", it is an environment, ecosystem, etc. It's not interesting to narrowly focus on the efficiency of the interpreter. Sure, but that's how people construe the post, which I think the author knows too. The post could have been accurately titled "Python has certain libraries that are fast enough for HPSC", but that wouldn't have generated nearly as much interest as "Why I still use Python for HPSC". People want to see others say good things about their favourite language, which in this case is Python. I knew where the article was going (with the libraries), but still wanted to read it because even I wanted to see someone compliment Python itself, because it used to be my "primary language". Python is a good language, but to the extent you're not using those highly optimized "C-libraries", it just doesn't perform well, and it's not suited for concurrency. That's a part of why I switched to Clojure.
- ajuc 11y agoObivously clojure, being written in Java (at least the intersting parts - collections and multithreading) - isn't fast (if Python isn't fast).
- sukulaku 11y agoRight, but I wouldn't claim it is. I'd say something like "The JVM is fast" :)
- andreasvc 11y agoJust because people construe the post that way doesn't mean they're right. Truth is not democratic. You can make any title more accurate by making it longer and more specific, but picking a good title is a trade off against other things as well. A charitable reader would not necessarily insist on the narrow interpretation of Python the language you insist on. And your title is not more accurate, because it's not just the existence of certain libraries, it's also the way they can be easily glued together and incrementally improved. Compare this to say Java, where you'd have to use JNI to use those same libraries, which is much more cumbersome to the point that most people prefer to write everything in Java. > People want to see others say good things about their favourite language To be honest I only think this only describes people that enjoy internet debates on programming languages. If what you are interested in is getting work done, you don't care about the merits of a particular tool in isolation but about end results. Hypothetically, you could find the "perfect" language but if it doesn't have users or libraries, it's of no use, and therefore the insistence of discussing only this or that language is pointless.
- RogerL 11y agoThe question is: what language should I use for HPC. An answer is Python. If you use C for HPC (the way you mean it) it will be slow as a dog. Because HPC is done with BLAS, LAPACK, etc. If you do HPC in C you are calling into BLAS and LAPACK. They are Fortran libraries. Anything else is dog slow in comparison (a slight stretch, but not by much). So, the "real" answer is Fortran. But not a lot of people are sitting at their desk writing Fortran for scientific computing these days. They are writing Python, C, or C++ for the most part. All of which use libraries that call into the Fortran libraries. That's all this article is saying, and we all understand it. No one is wringing their hands about what language the libraries are written in unless you are trying to write one of those libraries. Working professionals use Python for scientific software because it excels at data munging, making reports, and very high speed computation. Everyone gets that you need to add some libraries beyond the libraries provided from the base install.
- JustSomeNobody 11y agoThe point I think a lot of people are missing is that we've always used optimized libraries no matter what language we've used. C devs would use hand optimized assembly when speed was critical. There's no perfect language that just does everything.
- mcnamaratw 11y agoTo be fair, the article doesn't say "Python is fast." It says "Python is slow," and then goes on to say something like "But if most of your heavy-duty calculation involves calling prewritten C routines, you can do your development work in Python without getting killed on performance." Language discussions always seem to go down the same dismal tube in the end: "Is C > Python, or is Python > C?"