6 ms·

> So, let's prove some people wrong and let's see how we can improve performance of our Python programs and make them really fast! I have to say, the desperate

by zmmmmm 7y ago

> So, let's prove some people wrong and let's see how we can improve performance of our Python programs and make them really fast! I have to say, the desperate lengths Python programmers will go to to use it for things it was not meant for rather than learn or use other languages is one of the aspects I most dislike about it. However fast you make it, the same effort would have made it that much faster again in a performant language.

Waterluvian 7y ago
I love Python as a glue language. So much heavy lifting done in numpy or opencv or whatnot. But Python as the interface makes it trivial to explore, experiment, and glue together a workflow, especially when the solution is unclear. Then at some point if Python isn't needed because you know exactly what you want your software to do, rewrite it in C++ or whatever. Also with CFFI and other interoperable libraries, it's really quite easy to write some heavy work in a more appropriate language and call into it.
- socialdemocrat 7y ago
  For that kind of workflow you would be far better off with e.g. Julia. You get the same advantages as Python as having a language you can experiment with until you find a solution. Only difference is the optimization step later does not involve having to rewrite in another language. If you already know Python, and Python packages already do all you will ever need then sure stick with that. But I don't get why people would go to such lengths to avoid using a new language. Being proficient in Julia is a lot less work than maintaining proficiency in Python and C++.
  - Waterluvian 7y ago
    Likely because of this: https://pypl.github.io/PYPL.html https://pypl.github.io/PYPL.html
    - qwerty456127 7y ago
      OMG. Until now I didn't realize Cobol is more popular than Haskell and Delphi. I had just read there are ~2.5 Cobol programmers left in the world, who are old like Gandalf, enjoy ridiculously high salaries and can't retire because nobody learns Cobol any more while the world needs somebody to maintain those legacy systems that still run its economy. While Delphi used to be the PHP of the desktop world until very recently (and could hardly be expected to decline so fast) and Haskell seems to be the computer science lingua franca.
      - anon73044 7y ago
        >The more a language tutorial is searched, the more popular the language is assumed to be. It is a leading indicator. The raw data comes from Google Trends. That's the problem, nobody is actively learning Cobol these days and nobody knows how much is running out there in the wild, because none of the big banks or credit companies will actually admit it. You joke but the jobs are still out there, still being posted and companies are still hiring. https://www.wellsfargojobs.com/job/irving/apps-systems-engineer-4-cobol-developer/1251/14783197 https://www.wellsfargojobs.com/job/irving/apps-systems-engin...
        pjmlp 7y ago
        And there are even compilers targeting .NET and Java. https://www.gtsoftware.com/products/netcobol/netcobol-for-net/ https://www.gtsoftware.com/products/netcobol/netcobol-for-ne... https://www.microfocus.com/en-us/products/visual-cobol/overview https://www.microfocus.com/en-us/products/visual-cobol/overv... And naturally cloud deployments. https://www.youtube.com/watch?v=z9cYwbDdobc https://www.youtube.com/watch?v=z9cYwbDdobc
  - leotaku 7y ago
    The last time I checked, using Julia was clunky at best with ridiculously high jit-compile times, packages that refused to build on my machine etc.. What is more, many of the "best" Julia libraries were seemingly just linked-in Python code. I don't mean to discredit the advantages Julia clearly has over Python, but these are just the kinds of problems that make people like me stick with tried and tested last-gen languages like Python.
    - socialdemocrat 7y ago
      Did you ever check after 1.0 was released? In the earlier days it was a lot of problems with packages. Totally agree. JIT compile times are much better now. A lot of the issues are simply that people have not learned a sensible workflow with Julia. Python guys have a lot of habits that don't translate well to Julia. I know because I work daily with two hardcore python guys. I notice all the time how we approach problems in very different ways. Python guys seem to love making lots of separate little programs they launch from the shell. Or they just relaunch whole programs all the time. In Julia in contrast you focus on packages from the get go and you work primarily inside the Julia REPL. You run Revise.jl package which picks up all the changes you make to your Julia package. I guess it just depends on the workflows you are used to. For me it is the opposite. Whenever I have to jump into our Python code base I absolutely hate it. It is very unnatural for me to work in the Python way. I also find Python code kind of hard to read compared to Julia code. But I know Python coders have the opposite problem. Basically Python guys look a lot at module names when reading code. Julia developers look more at types. The difference makes some sense since you don't really write types in Python code. I found that the new Python type annotation system helped me feel at home in Python.
- pdimitar 7y ago
  For the pretty much perfect language, try Erlang or Elixir. The runtime guarantees are like no other languages, and it can easily drop down to C, C++, Rust and several others when needed.
  - hopia 7y ago
    Neither of those is arguably very expressive as a language though. It's the runtime and the built-in libraries around it (OTP) that holds the power.
    - pdimitar 7y ago
      What do you mean by "expressive"?
      - hopia 7y ago
        Able to abstract concisely at a high level, provides decent facilities for modeling business logic in a succinct yet correct manner etc. Elixir and Erlang both lack a type system and maintain a focus on keeping the language constructs simple rather than providing various high level abstractions some other more expressive languages have.
        pdimitar 7y ago
        I mean sure, you are right, but is there a language that is expressive by your criteria? You seem to be describing DSLs -- that can be done by all LISPs and some others -- and not programming languages per se. Elixir has very powerful macros by the way, they are compile-time and not the runtime `method_missing` stuff that Ruby does, so they are basically code generation that you don't get to see but get all the benefits from. With those macros you can go quite far creating business DSLs with Elixir (and a bunch more language, in the interest if full honesty). That's why many people qualify Elixir as "LISP-y". The lack of static typing is indeed something that is poking my eyes as well, but so far I have been managing. The extra cognitive load due to it -- plus the need to utilise the strong but dynamic typing system -- is definitely there though, cannot deny that.
- gameswithgo 7y ago
  But this is a benefit not of python but of the ecosystem around it. We should be making those libraries, as easy to use, in other languages.
akdor1154 7y ago
I love Python and you are 100% correct.
Eikon 7y ago
> [...]the desperate lengths Python programmers will go to to use it for things it was not meant for rather than learn or use other languages[...] I don't think it's an issue of not wanting to learn other languages. If you really like screwdrivers and go to screwdriving events, have a collection of screwdrivers, you may end up living in a echo chamber where you and your peers are convinced using a screwdriver is a good tool to plant a nail.
- qfwfq_ 7y ago
  I think this is exactly how R's accreted features to make it do things that it was never designed to do. When the "tool you use" becomes the "kind of developer you are," things get a little restrictive.
  - SAI_Peregrinus 7y ago
    It's also how languages like Scala become "everything and the kitchen sink" multi-paradigm monsters. People making the tool want it to do everything, so that they can get all the developers, so they make it a functional object-oriented imperative procedural declarative hodgepodge of 15 different barely-mutually-operable sub-languages, and you get a mess.
112 7y ago
You are right, the article doesn't deliver and its title is just clickbait. This is the kind of shallow content that's flooding dev.to nowadays.
taneq 7y ago
> However fast you make it, the same effort would have made it that much faster again in a performant language. If you're trying to make something go 'really fast' these days, that means either (a) some kind of vectorization, or (b) pushing work onto a GPU. In either case Python is unlikely to perform meaningfully worse than any other language, since the host language isn't doing much anyway.

by zmmmmm 7y ago

Waterluvian 7y ago

I love Python as a glue language. So much heavy lifting done in numpy or opencv or whatnot. But Python as the interface makes it trivial to explore, experiment, and glue together a workflow, especially when the solution is unclear. Then at some point if Python isn't needed because you know exactly what you want your software to do, rewrite it in C++ or whatever. Also with CFFI and other interoperable libraries, it's really quite easy to write some heavy work in a more appropriate language and call into it.

socialdemocrat 7y ago
For that kind of workflow you would be far better off with e.g. Julia. You get the same advantages as Python as having a language you can experiment with until you find a solution. Only difference is the optimization step later does not involve having to rewrite in another language. If you already know Python, and Python packages already do all you will ever need then sure stick with that. But I don't get why people would go to such lengths to avoid using a new language. Being proficient in Julia is a lot less work than maintaining proficiency in Python and C++.
- Waterluvian 7y ago
  Likely because of this: https://pypl.github.io/PYPL.html https://pypl.github.io/PYPL.html
  - qwerty456127 7y ago
    OMG. Until now I didn't realize Cobol is more popular than Haskell and Delphi. I had just read there are ~2.5 Cobol programmers left in the world, who are old like Gandalf, enjoy ridiculously high salaries and can't retire because nobody learns Cobol any more while the world needs somebody to maintain those legacy systems that still run its economy. While Delphi used to be the PHP of the desktop world until very recently (and could hardly be expected to decline so fast) and Haskell seems to be the computer science lingua franca.
    - anon73044 7y ago
      >The more a language tutorial is searched, the more popular the language is assumed to be. It is a leading indicator. The raw data comes from Google Trends. That's the problem, nobody is actively learning Cobol these days and nobody knows how much is running out there in the wild, because none of the big banks or credit companies will actually admit it. You joke but the jobs are still out there, still being posted and companies are still hiring. https://www.wellsfargojobs.com/job/irving/apps-systems-engineer-4-cobol-developer/1251/14783197 https://www.wellsfargojobs.com/job/irving/apps-systems-engin...
      - pjmlp 7y ago
        And there are even compilers targeting .NET and Java. https://www.gtsoftware.com/products/netcobol/netcobol-for-net/ https://www.gtsoftware.com/products/netcobol/netcobol-for-ne... https://www.microfocus.com/en-us/products/visual-cobol/overview https://www.microfocus.com/en-us/products/visual-cobol/overv... And naturally cloud deployments. https://www.youtube.com/watch?v=z9cYwbDdobc https://www.youtube.com/watch?v=z9cYwbDdobc
- leotaku 7y ago
  The last time I checked, using Julia was clunky at best with ridiculously high jit-compile times, packages that refused to build on my machine etc.. What is more, many of the "best" Julia libraries were seemingly just linked-in Python code. I don't mean to discredit the advantages Julia clearly has over Python, but these are just the kinds of problems that make people like me stick with tried and tested last-gen languages like Python.
  - socialdemocrat 7y ago
    Did you ever check after 1.0 was released? In the earlier days it was a lot of problems with packages. Totally agree. JIT compile times are much better now. A lot of the issues are simply that people have not learned a sensible workflow with Julia. Python guys have a lot of habits that don't translate well to Julia. I know because I work daily with two hardcore python guys. I notice all the time how we approach problems in very different ways. Python guys seem to love making lots of separate little programs they launch from the shell. Or they just relaunch whole programs all the time. In Julia in contrast you focus on packages from the get go and you work primarily inside the Julia REPL. You run Revise.jl package which picks up all the changes you make to your Julia package. I guess it just depends on the workflows you are used to. For me it is the opposite. Whenever I have to jump into our Python code base I absolutely hate it. It is very unnatural for me to work in the Python way. I also find Python code kind of hard to read compared to Julia code. But I know Python coders have the opposite problem. Basically Python guys look a lot at module names when reading code. Julia developers look more at types. The difference makes some sense since you don't really write types in Python code. I found that the new Python type annotation system helped me feel at home in Python.
pdimitar 7y ago
For the pretty much perfect language, try Erlang or Elixir. The runtime guarantees are like no other languages, and it can easily drop down to C, C++, Rust and several others when needed.
- hopia 7y ago
  Neither of those is arguably very expressive as a language though. It's the runtime and the built-in libraries around it (OTP) that holds the power.
  - pdimitar 7y ago
    What do you mean by "expressive"?
    - hopia 7y ago
      Able to abstract concisely at a high level, provides decent facilities for modeling business logic in a succinct yet correct manner etc. Elixir and Erlang both lack a type system and maintain a focus on keeping the language constructs simple rather than providing various high level abstractions some other more expressive languages have.
      - pdimitar 7y ago
        I mean sure, you are right, but is there a language that is expressive by your criteria? You seem to be describing DSLs -- that can be done by all LISPs and some others -- and not programming languages per se. Elixir has very powerful macros by the way, they are compile-time and not the runtime `method_missing` stuff that Ruby does, so they are basically code generation that you don't get to see but get all the benefits from. With those macros you can go quite far creating business DSLs with Elixir (and a bunch more language, in the interest if full honesty). That's why many people qualify Elixir as "LISP-y". The lack of static typing is indeed something that is poking my eyes as well, but so far I have been managing. The extra cognitive load due to it -- plus the need to utilise the strong but dynamic typing system -- is definitely there though, cannot deny that.
gameswithgo 7y ago
But this is a benefit not of python but of the ecosystem around it. We should be making those libraries, as easy to use, in other languages.

akdor1154 7y ago

I love Python and you are 100% correct.

Eikon 7y ago

> [...]the desperate lengths Python programmers will go to to use it for things it was not meant for rather than learn or use other languages[...] I don't think it's an issue of not wanting to learn other languages. If you really like screwdrivers and go to screwdriving events, have a collection of screwdrivers, you may end up living in a echo chamber where you and your peers are convinced using a screwdriver is a good tool to plant a nail.

qfwfq_ 7y ago
I think this is exactly how R's accreted features to make it do things that it was never designed to do. When the "tool you use" becomes the "kind of developer you are," things get a little restrictive.
- SAI_Peregrinus 7y ago
  It's also how languages like Scala become "everything and the kitchen sink" multi-paradigm monsters. People making the tool want it to do everything, so that they can get all the developers, so they make it a functional object-oriented imperative procedural declarative hodgepodge of 15 different barely-mutually-operable sub-languages, and you get a mess.

112 7y ago

You are right, the article doesn't deliver and its title is just clickbait. This is the kind of shallow content that's flooding dev.to nowadays.

taneq 7y ago

> However fast you make it, the same effort would have made it that much faster again in a performant language. If you're trying to make something go 'really fast' these days, that means either (a) some kind of vectorization, or (b) pushing work onto a GPU. In either case Python is unlikely to perform meaningfully worse than any other language, since the host language isn't doing much anyway.