Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Will Python become the dominant programming language?

Options
2»

Comments

  • Options
    #32
    14ned
    Registered Users Posts: 768 ✭✭✭14ned


    mahamageehad wrote: »
    Ah ok Niall, thanks for the extra info. I'm nowhere near that far along to actually understand all that just yet, but I've noted it for future reference. Currently I'm using Anaconda to separate out project environments so I can flip between Python 2.7 and 3.6 but I can see how it could be an issue in a live project.

    When you do get a chance, look into "stackless Python". Very cool, though a poor relation to say Erlang.

    Niall


  • Options
    #33
    Tar.Aldarion
    Moderators, Science, Health & Environment Moderators, Social & Fun Moderators, Society & Culture Moderators Posts: 60,090 Mod ✭✭✭✭Tar.Aldarion


    Sephiroth_dude wrote: »
    Which is used more in the industry, python 2 or 3?

    Not sure but you will have a lot of companies (like where I work) that will use 2.7 and not cater for 3.x at all, for the foreseeable future.

    As for the OP, I hope so, I love working with python.


  • Options
    #34
    srsly78
    Registered Users Posts: 7,157 ✭✭✭srsly78


    14ned wrote: »
    When you do get a chance, look into "stackless Python". Very cool, though a poor relation to say Erlang.

    Niall

    Basically useless because the various 3rd party packages won't work with it. Similarly with pypy and others. They claim experimental support for things like numpy but it just doesn't work! CPython is the only game in town if you care about the ecosystem.


  • Options
    #35
    Talisman
    Registered Users Posts: 6,120 ✭✭✭Talisman


    I've gotten back into using Python recently and have noticed that some things that are supposedly the Pythonic way of doing things are not the most performant. I pointed out a few simple to fix performance bottlenecks in code and the response was along the lines of "performance isn't my concern here, it's correctness".


  • Options
    #36
    counterpointaud
    Registered Users Posts: 403 ✭✭counterpointaud


    amen wrote: »
    A little off post but a 7% growth to 16% is not a 8.7% growth its actually a 124% growth.

    You're right sorry, I meant difference between 7% of total and 16% of total, not % growth.


  • Advertisement
  • Options
    #37
    Colonel Panic
    Registered Users Posts: 2,020 ✭✭✭Colonel Panic


    14ned wrote: »
    The single most common problem with most Python is poor performance. A skilled Python programmer writes code which is very competitive with any other programming language in terms of scaling curve, indeed a long standing argument I've been having with the C++ gurus is that well written Python programs have better scalability than well written C++ programs. The absolute speed of C++ hides the lousy scalability up to a point.

    The second most common problem is lack of portability. Too many Python devs only target some version of Python, usually 2.7. There are four major Python implementations (CPython, Jython, IronPython, PyPy (+stackless)), well written Python runs well on all four, and on both v2 and v3 language editions.

    Niall

    Are you on the Python not as scalable side?


  • Options
    #38
    14ned
    Registered Users Posts: 768 ✭✭✭14ned


    Colonel Panic wrote: »
    Are you on the Python not as scalable side?

    Other way round. Mine would be a minority opinion in the C++ world, a majority opinion in the Python world. The Python guys are right.

    People in the C++ world don't realise how poorly the C++ standard library scales. It was designed a very long time ago (> 25 years ago) back when you could consider malloc() to be free of cost and scalability didn't matter much because there was so little RAM anyway, 640Kb really was an ocean of RAM very few had access to. Python not only is much newer, but they've been systematically replacing internal algorithms to better fit modern hardware over time, so for example Python 3.2 or 3.3 (can't remember) replaced the old UTF-16 based implementation of unicode strings with a much faster UTF-8 one. Python code never noticed the difference, it just runs faster and scales better.

    C++ can't match that, though there are increasing calls for an STL v2 based on the Ranges TS. The Ranges TS implements Python like list comprehensions and generators for C++, should be landing in the C++ 20 standard or near to it. The Coroutines TS also adds stackless C++ like stackless Python, so things are improving, just fifteen years later than everyone else.

    I actually have a Google Summer of Code student looking into implementing the Ranges TS at compile time right now, the idea is you can run a ton of stuff in the compiler at compile time like looking up keys in maps, that way there is literally zero runtime overhead. C++ may be long behind the curve, but it gets there eventually.

    Niall


  • Options
    #39
    Colonel Panic
    Registered Users Posts: 2,020 ✭✭✭Colonel Panic


    Right, so when I think of scaling well with C++ code, I think about leveraging CPU cache by being good with data layout, custom allocators and task based parallelism, not the specifics of their respective standard libraries.


  • Options
    #40
    cnocbui
    Registered Users Posts: 19,955 ✭✭✭✭cnocbui


    Yes and no.

    Where speed of execution is critical, It isn't of much use.


  • Options
    #41
    14ned
    Registered Users Posts: 768 ✭✭✭14ned


    Colonel Panic wrote: »
    Right, so when I think of scaling well with C++ code, I think about leveraging CPU cache by being good with data layout, custom allocators and task based parallelism, not the specifics of their respective standard libraries.

    That's exactly the problem. C++'s standard libraries cause poor data layout, have lousy custom allocation, and non-existent task based parallelism. Python's are much better on all three fronts. Hence why well written C++ usually scales poorer than well written Python.

    Niall


  • Advertisement
  • Options
    #42
    Colonel Panic
    Registered Users Posts: 2,020 ✭✭✭Colonel Panic


    I dunno, I mean I concede that the C++ standard library has issues and missing components, but that nature of the language grants you the ability to improve these things.

    In Python, unless you're willing to write native implementations with Python bindings, I don't think you can call it more scalable, whatever that even means!

    I believe in what I see, a hybrid future!


  • Options
    #43
    14ned
    Registered Users Posts: 768 ✭✭✭14ned


    Colonel Panic wrote: »
    I dunno, I mean I concede that the C++ standard library has issues and missing components, but that nature of the language grants you the ability to improve these things.

    Dunno, me and my ilk have been pushing for STL v2 for many years. In fact I just finished writing an email just there to a WG21 member on the design for iostreams v2. I want STL iostreams taken out back and shot, zero backwards compatibility, and a radically more sensible design for iostreams v2.
    In Python, unless you're willing to write native implementations with Python bindings, I don't think you can call it more scalable, whatever that even means!

    Not true, you can reimplement Python core algorithms in Python with needing to drop to the C API. Python.Future (http://python-future.org/index.html) for example monkey patches in Python 3 replacements for Python 2 core objects like list, str, dict etc on a module by module basis. A fair chunk of that is pure Python. Then your Python 3 module can run on the Python 2 interpreter alongside Python 2 only code. Which is pretty cool.

    Niall


Advertisement