4 ms·

I just noticed http://arxiv.org/pdf/1507.03989v1.pdf http://arxiv.org/pdf/1507.03989v1.pdf (it's on todays HN). It claims that in Astronomy Python is used over

by todd8 11y ago

I just noticed http://arxiv.org/pdf/1507.03989v1.pdf http://arxiv.org/pdf/1507.03989v1.pdf (it's on todays HN). It claims that in Astronomy Python is used over twice as much as FORTRAN and even C/C++ is used more.

dekhn 11y ago
Nearly all astronomers who use Python are actually using Fortran and C++ - the python code is mostly wrappers on low-level libraries. So the claim of "use" is really what the astronmer sees in their programmer- not in the measure of instructions executed.
- TimSAstro 11y ago
  While I see what you're saying, I doubt you would claim to 'use' assembly when writing a C++ codebase - because (unless you're doing very low-level hand optimizations of the kind that get ever rarer), someone else has done the hard work of creating a compiler to do the translation for you. Same thing with NumPy et al, except one level higher up the abstraction stack.
  - dekhn 11y ago
    Actually, that's precisely what I do, except it's called machine language, not assembly. That is because assembly is an intermediate format above machine language (it's symbolic).
- ced 11y ago
  Yes, but from their perspective, it's an implementation detail. LAPACK could have been written in assembly language or APL, and their Python code would work just as well. Python/Matlab/IDL are important because it is easier to quickly write correct code than in C++/Fortran.
  - dekhn 11y ago
    Right, but if you say people "use" something, it's disingenous (for a scientific paper) to imply that implementation details don't matter. Had I written the paper (I'm a scientist, I work with astro data sets at times, and manage Python wrappers for Fortran and C++ libraries) I would have calculated this based on instructions executed, not lines of user-facing code. After all, if the code the astro people called was Pure Python, they wouldn't use python, as it would be too slow.
    - agumonkey 11y ago
      Reminds me of the 'made in X' fallacy. #!/usr/bin/env python from subprocess import Popen Popen("/usr/bin/some-fortran-binary") print("Once again python saves the day.")
  - math_and_stuff 11y ago
    Actually, many optimized BLAS/LAPACK implementations are not written in Fortran. Many are a mix of C and assembly exposed through the standard Fortran interface.

by todd8 11y ago

dekhn 11y ago

Nearly all astronomers who use Python are actually using Fortran and C++ - the python code is mostly wrappers on low-level libraries. So the claim of "use" is really what the astronmer sees in their programmer- not in the measure of instructions executed.

TimSAstro 11y ago
While I see what you're saying, I doubt you would claim to 'use' assembly when writing a C++ codebase - because (unless you're doing very low-level hand optimizations of the kind that get ever rarer), someone else has done the hard work of creating a compiler to do the translation for you. Same thing with NumPy et al, except one level higher up the abstraction stack.
- dekhn 11y ago
  Actually, that's precisely what I do, except it's called machine language, not assembly. That is because assembly is an intermediate format above machine language (it's symbolic).
ced 11y ago
Yes, but from their perspective, it's an implementation detail. LAPACK could have been written in assembly language or APL, and their Python code would work just as well. Python/Matlab/IDL are important because it is easier to quickly write correct code than in C++/Fortran.
- dekhn 11y ago
  Right, but if you say people "use" something, it's disingenous (for a scientific paper) to imply that implementation details don't matter. Had I written the paper (I'm a scientist, I work with astro data sets at times, and manage Python wrappers for Fortran and C++ libraries) I would have calculated this based on instructions executed, not lines of user-facing code. After all, if the code the astro people called was Pure Python, they wouldn't use python, as it would be too slow.
  - agumonkey 11y ago
    Reminds me of the 'made in X' fallacy. #!/usr/bin/env python from subprocess import Popen Popen("/usr/bin/some-fortran-binary") print("Once again python saves the day.")
- math_and_stuff 11y ago
  Actually, many optimized BLAS/LAPACK implementations are not written in Fortran. Many are a mix of C and assembly exposed through the standard Fortran interface.