7 ms·

The argument is bad but the headline has a point: the value of a language is the quality of its libraries and the community that maintains it. Python 3 seems li

The argument is bad but the headline has a point: the value of a language is the quality of its libraries and the community that maintains it. Python 3 seems like a mistake; it fractured the community and sent people away. (to golang, to scala, probably even to ruby). If I were a library maintainer on py2 I would have felt betrayed by py3. Suddenly print is a function? 'yield from' won't be available on the py2 branch? Yikes. C++ is an example of the serious negative consequences of language change. The language has been in flux for decades and the 3rd-party code shows it. Some fraction of good libraries rely on c++14 features. Many others duplicate in library code features that have been available in the language since c++11 or earlier. Boost, the 'missing standard library' for cpp, is something you either love or hate. The end result for c++ in 2016 is that large shops either (a) don't use it or (b) don't use the new features and have a slow acceptance process for 3rd-party libs. You can argue that the C community is healthier than C++ -- a ton of important system libraries are written in C and have bindings to tons of languages. Yes, they have problems (openssl cough), yes nobody understands unspecified behavior across compilers, but C has done a good job of supporting lots of platforms and staying relatively stable. Betraying the community can kill a language. Perl learned this lesson the hard way. Let's hope python can be saved.

deleted 10y ago
[deleted]
Alex3917 10y ago
Python still has the best libraries of any language, and almost every library has full Python 3 support. The real issue is with legacy codebases that are going to need to upgrade from Python 2.7 to 3.5 or else switch to PyPy by 2020
haimez 10y ago
Don't hitch your wagon this this garbage. If you think the 2 to 3 transition is a harbinger of doom, write your own blog post about it.
viraptor 10y ago
> Suddenly print is a function? from __future__ import print_function Now you've got print function in python2. > 'yield from' won't be available on the py2 branch? And 2.6 doesn't get set literals. And 2.5 doesn't get "with" statements. And ... There's got to be a cutoff somewhere. Or we'd just have an eternal 1.0 with all the features backported to it.
- ant6n 10y ago
  Well no. The problem is that py3 breaks backwards compatibility, without really a good reason. What's so much better about it? Why couldn't they sort py2 at least for module imports? Which is exactly opposite for c++11 - it doesn't break backwards compatibility, but I really want those new features. I think if it broke backwards compatibility, I'd still switch to the new c++. At work we use py2 and c++11...
  - viraptor 10y ago
    > Which is exactly opposite for c++11 - it doesn't break backwards compatibility Yes it does: https://stackoverflow.com/a/6402166/31667 https://stackoverflow.com/a/6402166/31667
  - MereInterest 10y ago
    The most visible changes, such as print being a function, are the easiest and most trivial to adapt to. They clean up the language, and can be automatically converted from one to the other. This can be pulled into python 2 with "from __future__" imports. The harder part is the string handling. In Python 2, you have one class, string, which is performing two different jobs. It is acting both as a holder for text, and as a holder for binary data. This sort of works, because ASCII looks like binary data if you squint it. If your users are English-only, then this probably sounds like a reasonable thing. Once you need to start supporting Unicode, this ambiguity causes a world of pain. On python 3, this ambiguity is removed. You have bytes, which are binary data, and strings, which are encoded text. No longer is there one class trying in vain to represent both concepts. This is also why automatic translation doesn't work, because the translator doesn't know which concept you were trying to user when you used a python 2 string. This is a rather low level change, which is why it took libraries so long to update, and why it couldn't be done without breaking backwards compatibility.
banachtarski 10y ago
I don't really hear that many complaints from the C++ community about what you're talking about. All those older libraries that pre-date C++11 still work fine and interoperate with no difficulties with even C++1z libraries. C++ is the language that has done feature adoption correctly in my opinion. Standardized, by committee, with forwards and backwards compatibility in mind.
- awinter-py 10y ago
  I'm with you. I like some of the changes in the C++ language. But I don't love the C++ 3rd-party ecosystem. Python's is very healthy. C++ is so unconcerned with modules they've been kicking the feature down the road spec by spec. I think it's now 'post-17'. (could be wrong). Rust is a language that's in the perf class of c++ but has built-in lifetime support and built in modules. It's ten times easier to do database or, say, SDL interaction in rust. And rust is barely 1.0! I don't know anyone who programs who doesn't use a ton of libraries. C++ just hasn't prioritized this part of programming.
clusmore 10y ago
>C++ is an example of the serious negative consequences of language change. From the outside looking in (as a non-C++ developer), for me the bigger problem is honestly that they left in the warts rather than just paving around them. Those who have followed C++ for its entire life cycle have probably been able to mostly keep up with what language features were mistakes and what the best way to do things is, but I can't imagine myself ever picking up C++ now and hoping to have any clue at all what to avoid without spending years learning the hard way (no pun intended). As a very basic example from C# (which I do use professionally), the fact that untyped collections still exist (and things like IEnumerable with explicit casts instead of IEnumerable<T>) is just pointless cruft that we'd be better off without. As far as I'm concerned, no code should ever depend on them, and any code that does should be forcibly broken to force people to fix it. We treat security flaws seriously by forcing people to fix things, why should we not do the same with features that are essentially bug-magnets?
- Pxtl 10y ago
  On c#, the numerous core libs that don't meaningfully support nullable primitives is the most infuriating thing.
- pas 10y ago
  http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
- emodendroket 10y ago
  > As a very basic example from C# (which I do use professionally), the fact that untyped collections still exist (and things like IEnumerable with explicit casts instead of IEnumerable<T>) is just pointless cruft that we'd be better off without. As far as I'm concerned, no code should ever depend on them, and any code that does should be forcibly broken to force people to fix it. We treat security flaws seriously by forcing people to fix things, why should we not do the same with features that are essentially bug-magnets? I mean this is an age-old argument but MS comes down very strongly on the other side because, like... what if nobody is working on that C# 3.0 code anymore but you need it for whatever reason? Well, I guess you're out of luck in the world where they just break ArrayList.
deleted 10y ago
[deleted]
kbenson 10y ago
A language must change, or it will be left behind, and become an esoteric toy. Even C has to deal with this. The only reason C is still popular is because of it's grandfathered status in so much of our infrastructure, and in many of the popular OS choices. A language that changes will alienate people, and lose people. Perl saw this. Python is seeing this. The way to guard against this is to keep backwards compatibility. That generally doesn't allow enough change in languages that provide enough constraints to make them popular for large engineering projects, whether open source or commercial. Lisp doesn't need to change much, it's malleable enough in many respects that you can implement whatever you need, but good luck getting large engineering projects done and maintained using it. Perl has the same problem. The only solution I see to stay relevant is to allow alienating users, but make sure those changes that alienate users are good enough to draw substitutes, enough to keep steady state, or preferably still grow slowly. Maybe prior users will even swing back in occasionally, and without the false sense of betrayal, they'll actually find they like the state of the language a few years later. For a while, at least. This seems like the end of the world to Python community members, and it seemed like the end of the world to Perl community members because of the prior status those languages held, where they are or were at the top of their respective niches. I doubt the Scala community worries about exactly the same things. Put another way, did you expect to still be writing Python the same way in 20 years, with only the popular libraries changed? If you did, did you think about what that would mean for the language, and what the community would look like at that time? I'll tell you. Perl. That's not necessarily a bad thing. I write Perl professionally, every day. I love it. It's not the worst thing, being stable and reliable. But you don't get to be top language in your niche and sit on your laurels at the same time. Change is good. Embrace the change. If you're lucky, you'll use many languages to program in your life and be happy. The only way I see anyone being happy using any single language forever is to bury their head in the sand and ignore everything else going on around them.
- joshlemer 10y ago
  >I doubt the Scala community worries about exactly the same things. Why do you single out Scala as being particularly different to Python and Perl?
fsloth 10y ago
The term 'C++ community' feels strange. It's like saying 'the combustion vehicle community' or something like that. As a software engineer I don't want a community or someone to bond over the tools I use, I just want my stable tool with a large industrial user base. It's an industrial tool, with an ecosystem provided by an industry, used to solve industrial problems. C++ can't change. It's a feature. Unless the code uses some non-standard extension it is guaranteed that the code you write today will compile tomorrow. Refactoring? Rewriting? We are talking of decades old codebases with millions of lines, filled with bugfixes to handle odd-but-critical cornercases. Software that is sold for hundreds of millions, that run businesses that execute billion dollar projects. Stability, utility man. Not so graceful, perhaps, or cuddly. But it works. Yeah, the language is still a bitch but it's at least a stable one with support from several industrial vendors. From cognitive or software design point of view it's a disaster though - people should be thoroughly vetted in some other more sane language before allowed to write C++ :)
mastazi 10y ago
> Let's hope python can be saved. Can you explain why Python would need to be saved? I mean every week on r/MachineLearning there is at least one new Python deep learning framework being launched[1], I wonder if you can mention any other language which is that healthy. [1] https://www.reddit.com/r/MachineLearning/search?sort=new&restrict_sr=on&q=flair%3AProject https://www.reddit.com/r/MachineLearning/search?sort=new&res...
- hartator 10y ago
  All stable versions of the big ML frameworks are still 2.7.
  - mastazi 10y ago
    Even if your statement was true (it's not)[1][2][3][4], how would that be a sign that Python is dying? [1] http://www.deeplearning.net/software/theano/install.html http://www.deeplearning.net/software/theano/install.html [2] https://www.tensorflow.org/versions/r0.11/get_started/os_setup.html https://www.tensorflow.org/versions/r0.11/get_started/os_set... [3] https://keras.io/#you-have-just-found-keras https://keras.io/#you-have-just-found-keras [4] https://lasagne.readthedocs.io/en/latest/user/installation.html https://lasagne.readthedocs.io/en/latest/user/installation.h...
    - aminorex 10y ago
      I think the author's point was not that python3 is dying. His point was that it deserved death, that 2.7 is flourishing, while 3 is failing to thrive, and reasons for this were postulated.
  - p10_user 10y ago
    Are there many ML frameworks that only work in 2.7? Scipy and numpy work in both 2.7 and 3.x, so I'd imagine (without being heavy in the field) that any new development using these scientific computing packages could be Python version agnostic as well. Is this generally not the case?
  - 10y ago
blub 10y ago
Errr... what?! C++ is a positive example of language change, because it keeps backwards compatibility, unlike Python where we're still having discussions about 2vs3 after 8 years. Nobody is having discussions about C++14 vs C++98, the latter is better period. A C++14 compiler will compile C++98 code just fine in most cases. If it doesn't you get a compile time error. People are complaining about the opposite, that C++ is keeping compatibility for too long and that it has too many features. Both strategies have their pros and cons, but breaking seems to have more negative effects. C has done a great job of supporting buffer overflows on lots of platforms and injecting safety errors in all software that uses those libraries.

deleted 10y ago

[deleted]

Alex3917 10y ago

Python still has the best libraries of any language, and almost every library has full Python 3 support. The real issue is with legacy codebases that are going to need to upgrade from Python 2.7 to 3.5 or else switch to PyPy by 2020

haimez 10y ago

Don't hitch your wagon this this garbage. If you think the 2 to 3 transition is a harbinger of doom, write your own blog post about it.

viraptor 10y ago

> Suddenly print is a function? from __future__ import print_function Now you've got print function in python2. > 'yield from' won't be available on the py2 branch? And 2.6 doesn't get set literals. And 2.5 doesn't get "with" statements. And ... There's got to be a cutoff somewhere. Or we'd just have an eternal 1.0 with all the features backported to it.

ant6n 10y ago
Well no. The problem is that py3 breaks backwards compatibility, without really a good reason. What's so much better about it? Why couldn't they sort py2 at least for module imports? Which is exactly opposite for c++11 - it doesn't break backwards compatibility, but I really want those new features. I think if it broke backwards compatibility, I'd still switch to the new c++. At work we use py2 and c++11...
- viraptor 10y ago
  > Which is exactly opposite for c++11 - it doesn't break backwards compatibility Yes it does: https://stackoverflow.com/a/6402166/31667 https://stackoverflow.com/a/6402166/31667
- MereInterest 10y ago
  The most visible changes, such as print being a function, are the easiest and most trivial to adapt to. They clean up the language, and can be automatically converted from one to the other. This can be pulled into python 2 with "from __future__" imports. The harder part is the string handling. In Python 2, you have one class, string, which is performing two different jobs. It is acting both as a holder for text, and as a holder for binary data. This sort of works, because ASCII looks like binary data if you squint it. If your users are English-only, then this probably sounds like a reasonable thing. Once you need to start supporting Unicode, this ambiguity causes a world of pain. On python 3, this ambiguity is removed. You have bytes, which are binary data, and strings, which are encoded text. No longer is there one class trying in vain to represent both concepts. This is also why automatic translation doesn't work, because the translator doesn't know which concept you were trying to user when you used a python 2 string. This is a rather low level change, which is why it took libraries so long to update, and why it couldn't be done without breaking backwards compatibility.

banachtarski 10y ago

I don't really hear that many complaints from the C++ community about what you're talking about. All those older libraries that pre-date C++11 still work fine and interoperate with no difficulties with even C++1z libraries. C++ is the language that has done feature adoption correctly in my opinion. Standardized, by committee, with forwards and backwards compatibility in mind.

awinter-py 10y ago
I'm with you. I like some of the changes in the C++ language. But I don't love the C++ 3rd-party ecosystem. Python's is very healthy. C++ is so unconcerned with modules they've been kicking the feature down the road spec by spec. I think it's now 'post-17'. (could be wrong). Rust is a language that's in the perf class of c++ but has built-in lifetime support and built in modules. It's ten times easier to do database or, say, SDL interaction in rust. And rust is barely 1.0! I don't know anyone who programs who doesn't use a ton of libraries. C++ just hasn't prioritized this part of programming.

clusmore 10y ago

>C++ is an example of the serious negative consequences of language change. From the outside looking in (as a non-C++ developer), for me the bigger problem is honestly that they left in the warts rather than just paving around them. Those who have followed C++ for its entire life cycle have probably been able to mostly keep up with what language features were mistakes and what the best way to do things is, but I can't imagine myself ever picking up C++ now and hoping to have any clue at all what to avoid without spending years learning the hard way (no pun intended). As a very basic example from C# (which I do use professionally), the fact that untyped collections still exist (and things like IEnumerable with explicit casts instead of IEnumerable<T>) is just pointless cruft that we'd be better off without. As far as I'm concerned, no code should ever depend on them, and any code that does should be forcibly broken to force people to fix it. We treat security flaws seriously by forcing people to fix things, why should we not do the same with features that are essentially bug-magnets?

Pxtl 10y ago
On c#, the numerous core libs that don't meaningfully support nullable primitives is the most infuriating thing.
pas 10y ago
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
emodendroket 10y ago
> As a very basic example from C# (which I do use professionally), the fact that untyped collections still exist (and things like IEnumerable with explicit casts instead of IEnumerable<T>) is just pointless cruft that we'd be better off without. As far as I'm concerned, no code should ever depend on them, and any code that does should be forcibly broken to force people to fix it. We treat security flaws seriously by forcing people to fix things, why should we not do the same with features that are essentially bug-magnets? I mean this is an age-old argument but MS comes down very strongly on the other side because, like... what if nobody is working on that C# 3.0 code anymore but you need it for whatever reason? Well, I guess you're out of luck in the world where they just break ArrayList.

deleted 10y ago

[deleted]

kbenson 10y ago

A language must change, or it will be left behind, and become an esoteric toy. Even C has to deal with this. The only reason C is still popular is because of it's grandfathered status in so much of our infrastructure, and in many of the popular OS choices. A language that changes will alienate people, and lose people. Perl saw this. Python is seeing this. The way to guard against this is to keep backwards compatibility. That generally doesn't allow enough change in languages that provide enough constraints to make them popular for large engineering projects, whether open source or commercial. Lisp doesn't need to change much, it's malleable enough in many respects that you can implement whatever you need, but good luck getting large engineering projects done and maintained using it. Perl has the same problem. The only solution I see to stay relevant is to allow alienating users, but make sure those changes that alienate users are good enough to draw substitutes, enough to keep steady state, or preferably still grow slowly. Maybe prior users will even swing back in occasionally, and without the false sense of betrayal, they'll actually find they like the state of the language a few years later. For a while, at least. This seems like the end of the world to Python community members, and it seemed like the end of the world to Perl community members because of the prior status those languages held, where they are or were at the top of their respective niches. I doubt the Scala community worries about exactly the same things. Put another way, did you expect to still be writing Python the same way in 20 years, with only the popular libraries changed? If you did, did you think about what that would mean for the language, and what the community would look like at that time? I'll tell you. Perl. That's not necessarily a bad thing. I write Perl professionally, every day. I love it. It's not the worst thing, being stable and reliable. But you don't get to be top language in your niche and sit on your laurels at the same time. Change is good. Embrace the change. If you're lucky, you'll use many languages to program in your life and be happy. The only way I see anyone being happy using any single language forever is to bury their head in the sand and ignore everything else going on around them.

joshlemer 10y ago
>I doubt the Scala community worries about exactly the same things. Why do you single out Scala as being particularly different to Python and Perl?

fsloth 10y ago

The term 'C++ community' feels strange. It's like saying 'the combustion vehicle community' or something like that. As a software engineer I don't want a community or someone to bond over the tools I use, I just want my stable tool with a large industrial user base. It's an industrial tool, with an ecosystem provided by an industry, used to solve industrial problems. C++ can't change. It's a feature. Unless the code uses some non-standard extension it is guaranteed that the code you write today will compile tomorrow. Refactoring? Rewriting? We are talking of decades old codebases with millions of lines, filled with bugfixes to handle odd-but-critical cornercases. Software that is sold for hundreds of millions, that run businesses that execute billion dollar projects. Stability, utility man. Not so graceful, perhaps, or cuddly. But it works. Yeah, the language is still a bitch but it's at least a stable one with support from several industrial vendors. From cognitive or software design point of view it's a disaster though - people should be thoroughly vetted in some other more sane language before allowed to write C++ :)

mastazi 10y ago

> Let's hope python can be saved. Can you explain why Python would need to be saved? I mean every week on r/MachineLearning there is at least one new Python deep learning framework being launched[1], I wonder if you can mention any other language which is that healthy. [1] https://www.reddit.com/r/MachineLearning/search?sort=new&restrict_sr=on&q=flair%3AProject https://www.reddit.com/r/MachineLearning/search?sort=new&res...

hartator 10y ago
All stable versions of the big ML frameworks are still 2.7.
- mastazi 10y ago
  Even if your statement was true (it's not)[1][2][3][4], how would that be a sign that Python is dying? [1] http://www.deeplearning.net/software/theano/install.html http://www.deeplearning.net/software/theano/install.html [2] https://www.tensorflow.org/versions/r0.11/get_started/os_setup.html https://www.tensorflow.org/versions/r0.11/get_started/os_set... [3] https://keras.io/#you-have-just-found-keras https://keras.io/#you-have-just-found-keras [4] https://lasagne.readthedocs.io/en/latest/user/installation.html https://lasagne.readthedocs.io/en/latest/user/installation.h...
  - aminorex 10y ago
    I think the author's point was not that python3 is dying. His point was that it deserved death, that 2.7 is flourishing, while 3 is failing to thrive, and reasons for this were postulated.
- p10_user 10y ago
  Are there many ML frameworks that only work in 2.7? Scipy and numpy work in both 2.7 and 3.x, so I'd imagine (without being heavy in the field) that any new development using these scientific computing packages could be Python version agnostic as well. Is this generally not the case?
- 10y ago

blub 10y ago

Errr... what?! C++ is a positive example of language change, because it keeps backwards compatibility, unlike Python where we're still having discussions about 2vs3 after 8 years. Nobody is having discussions about C++14 vs C++98, the latter is better period. A C++14 compiler will compile C++98 code just fine in most cases. If it doesn't you get a compile time error. People are complaining about the opposite, that C++ is keeping compatibility for too long and that it has too many features. Both strategies have their pros and cons, but breaking seems to have more negative effects. C has done a great job of supporting buffer overflows on lots of platforms and injecting safety errors in all software that uses those libraries.