6 ms·

I think that that's rather dismissive of a language that runs huge web, scientific, and general purpose applications daily.

pjmlp 10y ago
It might be, but that it is usually a consequence of not knowing any better or making use of existing libraries. Just like people learned 8-bit BASIC and went on to do business applications and games on it. I went Z80 ASM instead. Personally I would only use Python for shell scripting and advise for using Julia instead. Of course, others see it differently.
- goatlover 10y ago
  Julia's nice, but it's playing catch up to R & Python. Name any statistical algorithm, and R probably has it. Name any scientific field, and there's probably a Python library for it.
- wolf550e 10y ago
  Some people are very productive in Django and Rails (and the like), in non-performant languages. Many sites never grow to the size where running on the JVM (or AOT-compiled Go) would save you money from fewer servers vs. more coder-hours.
- JPKab 10y ago
  Julia? Look, I enjoy playing with Julia, but have you actually used it? Because most of the people I meet who turn up their nose at Python and say nice things about Julia haven't ever used Julia. It's got great potential but has some major gaps and warts, and is just plain dog shit slow for certain things compared to SciPy, which, you may not be aware, is basically C and Fortran code wrapped in Python API.
  - pjmlp 10y ago
    I do follow Julia development and I am aware that it isn't quite there, but at least their community does embrace JIT compilation, not like Python that PyPy is just yet another project, ignored by the reference implementation. > SciPy, which, you may not be aware, is basically C and Fortran code wrapped in Python API. Which for me personally means, that I would rather C and Fortran directly or better yet, a C++, .NET or Java binding to them.
    - orf 10y ago
      > Which for me personally means, that I would rather C and Fortran directly or better yet, a C++, .NET or Java binding to them. Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages.
      - pjmlp 10y ago
        Scala, Clojure, F# also allow it, with the added benefit of industrial strength JIT/AOT compilers.
        orf 10y ago
        Except without the great Python ecosystem and without great projects like Numpy/Scipy
        pjmlp 10y ago
        Numpy/Scipy are only relevant to a minor set of computer users, and even then, there are alternatives like LANPACK and BLAS. Also Java and .NET ecosystems are just a little bigger than Python.
        orf 10y ago
        > there are alternatives like LANPACK and BLAS. LANPACK + BLAS = scipy > Numpy/Scipy are only relevant to a minor set of computer users.. > ... Java and .NET ... Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages.
        pjmlp 10y ago
        > LANPACK + BLAS = scipy Thanks, I already knew that. > Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages. Hence we are back at Scala, Clojure, F#, enjoying the respective AOT/JIT native code compilers, and integrating with that highly-optimized C/Fortran code.
  - tavert 10y ago
    > is just plain dog shit slow for certain things compared to SciPy Do you have real examples here or is this just FUD? SciPy is not known for using absolute state of the art algorithms or perfectly optimized implementations. It can be pretty easy to improve on the naively implemented or legacy pieces of SciPy, e.g. http://tullo.ch/articles/python-vs-julia/ http://tullo.ch/articles/python-vs-julia/
- petters 10y ago
  This made be wary of Julia: http://danluu.com/julialang/ http://danluu.com/julialang/

pjmlp 10y ago

It might be, but that it is usually a consequence of not knowing any better or making use of existing libraries. Just like people learned 8-bit BASIC and went on to do business applications and games on it. I went Z80 ASM instead. Personally I would only use Python for shell scripting and advise for using Julia instead. Of course, others see it differently.

goatlover 10y ago
Julia's nice, but it's playing catch up to R & Python. Name any statistical algorithm, and R probably has it. Name any scientific field, and there's probably a Python library for it.
wolf550e 10y ago
Some people are very productive in Django and Rails (and the like), in non-performant languages. Many sites never grow to the size where running on the JVM (or AOT-compiled Go) would save you money from fewer servers vs. more coder-hours.
JPKab 10y ago
Julia? Look, I enjoy playing with Julia, but have you actually used it? Because most of the people I meet who turn up their nose at Python and say nice things about Julia haven't ever used Julia. It's got great potential but has some major gaps and warts, and is just plain dog shit slow for certain things compared to SciPy, which, you may not be aware, is basically C and Fortran code wrapped in Python API.
- pjmlp 10y ago
  I do follow Julia development and I am aware that it isn't quite there, but at least their community does embrace JIT compilation, not like Python that PyPy is just yet another project, ignored by the reference implementation. > SciPy, which, you may not be aware, is basically C and Fortran code wrapped in Python API. Which for me personally means, that I would rather C and Fortran directly or better yet, a C++, .NET or Java binding to them.
  - orf 10y ago
    > Which for me personally means, that I would rather C and Fortran directly or better yet, a C++, .NET or Java binding to them. Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages.
    - pjmlp 10y ago
      Scala, Clojure, F# also allow it, with the added benefit of industrial strength JIT/AOT compilers.
      - orf 10y ago
        Except without the great Python ecosystem and without great projects like Numpy/Scipy
        pjmlp 10y ago
        Numpy/Scipy are only relevant to a minor set of computer users, and even then, there are alternatives like LANPACK and BLAS. Also Java and .NET ecosystems are just a little bigger than Python.
        orf 10y ago
        > there are alternatives like LANPACK and BLAS. LANPACK + BLAS = scipy > Numpy/Scipy are only relevant to a minor set of computer users.. > ... Java and .NET ... Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages.
        pjmlp 10y ago
        > LANPACK + BLAS = scipy Thanks, I already knew that. > Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages. Hence we are back at Scala, Clojure, F#, enjoying the respective AOT/JIT native code compilers, and integrating with that highly-optimized C/Fortran code.
- tavert 10y ago
  > is just plain dog shit slow for certain things compared to SciPy Do you have real examples here or is this just FUD? SciPy is not known for using absolute state of the art algorithms or perfectly optimized implementations. It can be pretty easy to improve on the naively implemented or legacy pieces of SciPy, e.g. http://tullo.ch/articles/python-vs-julia/ http://tullo.ch/articles/python-vs-julia/
petters 10y ago
This made be wary of Julia: http://danluu.com/julialang/ http://danluu.com/julialang/