> Currently you cannot run Python 2 inside the Python 3 virtual machine. Since I cannot, that means Python 3 is not Turing Complete and should not be used by anyone.
I did the same. I honestly wonder if there is a single other developer on earth who is troubled by the inability to write a Python 2 runtime in Python 3.
A programming language "is said to be Turing complete or computationally universal if it can be used to simulate any single-taped Turing machine" [1]. This author doesn't seem to understand this concept properly.
I'm pretty sure that if you understand both Turing completeness and the practice of actual programming, then you know that in most cases the one has virtually nothing to do with the other. (Which is not meant at all to imply that the author of linked article understands Turing completeness, just that even though he doesn't seem to he could still be excellent at teaching programming.)
I'm wondering that here. The whole article feels over-the-top, perhaps it's a well crafted parody, an extreme sense of sarcasm? May be he is a Python 3 lover after all.
In my experience a lot of the problems with automatically converting existing Python 2 code to Python 3 code is that the Python 2 code usually makes fundamentally broken assumptions when it comes to unicode and bytes.
This is what the author doesn't get- the fact that Python 2 makes no distinction between bytes-like objects and string-like objects is a bug, not a feature. He finds his code so awful to migrate because he has built it on a contrary assumption.
I was working on a side project and ended up upgrading because I could figure out how Python was encoding my data. I got so frustrated with the semantics I found it easier to jusy upgrade.
Definitely disagree. I am a literal genius, wrote compilers, learned a dozen programming languages for fun, but prefer to do hard things. Yes p2 handling of coding is broken, but p3 is much worse. Making a theoretical argument about a pragmatic problem is a category mistake. And it's not even the core of Zed's expressed concern, which is the arrogant and abusive manipulation of the user community in service of the interests of self-obsessed project.
such smart. impressed. "p2" "p3". knows unique terminology. literal genius. so smart. A dozen programming languages just for fun? You definitely know what you're talking about and have very worthwhile contributions. People should listen to you.
I like what you said about self-obsessed project. It's clear that you have a very well reasoned position, not just opinion. What you say makes irrefutable sense.
Correct me if I'm wrong, but the idea of perl6 was announced in 2000, and perl6 was finally published in 2015. So there was a 15 year gap when perl5 was perceived on its way to become obsolete, but perl6 was not available.
I am unsure when the idea of python3 (first as python 3000) came to general knowledge, but it must have been some time between 2000 and 2004. Then python3 was published in 2008.
So the time between obsoleting the old version, before the new version was available, was notably shorter with python.
I thought there was a release in the interim that broke backwards compatibility and the went back to the drawing board. But it's that long ago I might be confusing it with Netscape.
There's also a good chance I'm confusing perl and parrot.
I also can't run Python 2 by passing it into a C compiler. Man, I should publish a paper on this- they thought C was Turing-complete, but I proved them wrong!
Considering how C has been targeted for all sorts of nonsense, I suspect that your argument would be somehow used as irrefutable proof that C is outdated and deprecated.
At least that's the conclusion that is repeatedly forced upon C, no matter what the argument is.
Yes, the author doesn't know what he's talking about.
But people talking about Turing completeness in a real programming language (usually in the form of "x is Turing complete, therefore you couldn't ask for more") almost always haven't got a clue.
Unlambda as a language may be a joke (the funny kind), but learning it is incredibly enlightening, and makes you understand some fundamental concepts of computer science.
As such, I think it represents one of the most enlightening esoteric languages out there together with Brainfuck.
We both agree, I'm just using this as a pretext to share this intriguing piece of knowledge. I find the concept much more intuitive than "getting back unused memory".
Especially when you look at the 90% memory usage on your OS, it still make sense with the "infinite memory simulation" definition.
> But people talking about Turing completeness in a real programming language (usually in the form of "x is Turing complete, therefore you couldn't ask for more") almost always haven't got a clue.
There is a fun quote about that...
"There are those who tell us that any choice from among theoretically-equivalent alternatives is merely a question of taste. These are the people who bring up the Strong Church-Turing Thesis in discussions of programming languages meant for use by humans. They are malicious idiots. The only punishment which could stand a chance at reforming these miscreants into decent people would be a year or two at hard labor. And not just any kind of hard labor: specifically, carrying out long division using Roman numerals. A merciful tyrant would give these wretches the option of a firing squad. Those among these criminals against mathematics who prove unrepentant in their final hours would be asked to prove the Turing-equivalence of a spoon to a shovel as they dig their graves."
Yea I skimmed the rest. This makes me ashamed that I even bought the guys book (Learn Python the Hard Way). His attitude is what is going to kill python, not python 3. I moved from Perl 5 to Python 3 hoping to flee the internal dev fighting and attitudes, yet here I am again.
I'll say this, at Pycon 2016 I attended some dev sprints/hackathons with the python 3 developers. Python 2 is no where on their radar, its dead. They have moved on. There will be no additional compatibility layers or any of that. All of the mainline libraries that everyone uses (django, sql alchemy, etc ) have moved on to python 3. If you haven't, you should to.
py3.3 support is at alpha level. py3.5 support is in the pipeline and already available for testing. It's unlikely they'll do any effort that's targeting py2 specifically anymore.
Then you missed his crazy notion of what static typing is and his failure to understand the difference between a string and a byte sequence. It's incredible that someone who knows so dangerously little about Unicode has written a web server that is so popular in the Ruby community. It says something about the quality of the language's ecosystem.
> Python 3 has been purposefully crippled to prevent Python 2's execution alongside Python 3 for someone's professional or ideological gain.
I can't tell if Zed's referring to python3 doing a fork()/exec() of a python2 not working correctly or if he wants/expects some kind of inter-language import or "linking" among files written for respective language versions. What's he getting at?
Is there really something that prevents you from executing python2 at the same time as python3? (I tried a simple program "os.system('python3 -c \'print ("hello")\'')" and it worked just fine.
I'm pretty sure what he wants to say is that it should let you use libraries written for an older version of Python than you are using, much like the CLR would do if you wanted to use a library written using an older version of C# than you're using (or a different language targeting the CLR, for that matter). I'm pretty sure the claim that Python 3 is "not Turing-complete" is just a hyperbolic mockery of the claim that that isn't possible to do.
N.B.: I haven't worked with Python so if you can actually do this somehow let me just say that that's not the impression the article left me with.
First I spit my coffee when I read that too, but let me play devil's advocate (because I pretty much disagree with the entirety of his rant) : he's pointing out that since it's technically feasible to write a Python 2 interpreter in Python 3, and since it should even be pretty easy since the two languages do not differ immensely, then the only reason why it hasn't been done and there's no -2 flag to python3 has to be an ideological reason, a manipulation by the core devs to impose their ideas by force.
It's extremely badly conveyed but that's what I got out of it by keeping reading.
I do disagree with him on all the rest though, especially strings. It didn't "just work" before, it failed silently and who knows how much disaster he or his readers have caused because of it. Now at least you can't be wrong anymore. For a language heavily used on the web, it's hugely important to understand where your strings are coming from and where they're going to, and how.
Besides, Python is not a frigging "beginners language". Just because Python (and admittedly especially Python 2) is generally easy to grasp as a first language doesn't mean it's its purpose, nor should it constrain itself toward this goal. It's used in a million of different areas, including pretty sensitive ones. It's now become a more mature language, reaching for exactitude and consistency. Just because Zac no longer has an easy toy language to point script kiddies to so they can "learn to program" by reading one website doesn't mean Python is to blame.
Python was one of the first languages I've tried I actually enjoyed programming in.
I hope to continue leveraging my investment in learning python by using it for a long time.
So far I haven't been forced to use Python 3.
I've tried a few times but always found it easier to just go back to python (2.7).
I figure eventually I have to use Python 3 but at this point, my life has been fine without upgrading to python3.
As a writer of "quick n' dirty" webapps for internal use, I use python3 because philosophically, I want to help the world move forward, and the standard library has more stuff in it.
Ditto. I have submitted at least 10 PRs to fix Python3 bugs in OSS projects directly because of this. So perhaps I have made the world .000001% better.
The lack of type checking makes it much harder to coordinate right inputs and outputs. Doable, but makes the overhead much harder than when you do have it.
I switched around 3.1, though granted I was still a novice programmer then and didn't have to port any legacy code. I had so many issues with Unicode in Python 2 (some may have been my own ignorance at the time, but with 3 a lot of those issues magically disappeared). Since text processing / NLP is my main focus, it was an easy decision to switch.
On the other hand, I never suggest Learn Python The Hard Way or Codecademy to any new programmer, because I don't want them to ask me down the line "why you directed me to an obsolete Python course?". I think I'm not the only one. So I'm not sure what's the net result of those decisions made by the two sites, do they really help in keeping Python 2 alive?
I attended a few newbie classes at pycon2016. A few of them suggested Learn Python The Hard Way, to which I pointed out how the author states to never try installing python 3 on the first page.
The author should essentially be banned from community and his book no longer recommended after that lest someone believes him.
You're essentially giving up great features like async keyword and proper encoding handling getting nothing in return. The few libraries that are still Python 2 only should be ignored.
I also saw that but gave the author benefit of doubt that may be the book was written years ago and not updated. I have completed switched to python3 for almost 2 years now.
... Not only is this blatantly false, but the author acknowledges it as such and seems to think that it is still OK to write this sort of sentence. Backing a pure falsehood with anecdotal support from "actual Python project developers" does nothing to change its veracity. I can't respect anything else in this article after seeing this kind of sensationalism.
Perhaps the author doesn't understand Turing-completion (I'll give the author the benefit of the doubt), but even if so it's inexcusable to throw around this sort of technical language this casually.
> The fact that you can't run Python 2 and Python 3 at the same time
I'm confused by this statement. I can start a python2 interpreter, background it, then start a python3 interpreter. Is there some other area that they inhibit each other in?
It sounds like the author's just miffed about incompatibilities in general -- specifically, that they can't (necessarily) import python 2 code whilst running under a python 3 interpreter and vice versa.
The thing about Zed is that his shtick was originally a joke: a parody of overconfident asshole programmers. But... well, like Orwell said, "He wears a mask, and his face grows to fit it."
"I’ll add one more thing to the people reading this: I mean business when I say I’ll take anyone on who wants to fight me. You think you can take me, I’ll pay to rent a boxing ring and beat your fucking ass legally."
This author is nuts.
"Python" and "dead language" in same sentence? Maybe if it was Perl or Java, I'd have understood.
P.S: I'm really sorry Java guys, I know Java isn't going to die, atleast not for another 100 years, but since I don't like it much, I'm putting it in the list here.
There are parts of Python that look like it wants programmers do low level compiler job and I can't understand why. This is one of them. Python can do %s string interpolation without some s'' s-strings so I wonder why it needs this f-string thing. Many languages can do string interpolation without having developers babysitting the interpreter. In 2016 we have the CPUs to make it happen the other way around.
> In the programming language theory there is this basic requirement that, given a "complete" programming language, I can run any other programming language. In the world of Java I'm able to run Ruby, Java, C++, C, and Lua all at the same time. In the world of Microsoft I can run F#, C#, C++, and Python all at the same time. This isn't just a theoretical thing. There is solid math behind it. Math that is truly the foundation of computer science.
Pretty sure Zed's playing a joke on experienced programmes. He's clearly mentioned that the book is for complete beginners and that's why the entire section for experienced programmers is crap.
Funny how many haven't seen it and are arguing pointlessly.
Is this actually a joke? I'm still kind of reeling. The typos, the technical inaccuracies, the logical fallacies, all bundled together... Is it trying to satirize something? If not, what is the blog post trying to do?
Ah but where's the fun in that? Just look at the number of people who've jumped the gun. Makes me wonder about the media and how we consume information in general...
Can the conclusion stand if the arguments are not correct? I'm sure there are other, better arguments out there, but after reading this from top to bottom I'm getting the idea that the resistance to Python 3 is mostly irrational.
> Can the conclusion stand if the arguments are not correct?
It can; arguing it can't would be an 'argument from fallacy', itself a fallacy.
Put another way, I can make up a totally absurd, incorrect argument that the sky is blue, but the sky is still blue. I can also make up a totally absurd, incorrect argument that the sky is green, but it isn't. An argument that doesn't hold water doesn't say anything useful about the conclusion either way.
I don't know how much it is Python shooting itself in the foot, I wonder if it's not a management issue. Though he may be stubborn, I can't see the 2 v 3 split happening under Rob Pike - I think this is fundamentally a Guido problem.
If Guido had said "2 is done. Deal with it, fuck you." a long time ago, this wouldn't be an issue today. Breaking language changes are nothing new, but mgmt this weak is.
Hell, I primarily work in C# and I LOVE the breaking changes of .NET Core and Standard. They tore the garbage out, and it runs on Linux. Awesome!
The vast majority of C# projects are not .NET Core but using the old, backwards-compatible stuff. And it's kind of nice that you can have that huge back catalogue of stuff even as you use the latest C# features.
He's well known for his hyperbole and ranting but he's also intelligent and usually able to back up his claims with some kind of argument.
There are so many clearly false claims in this piece though I assume it's just trolling.
As I mentioned in another thread the OED's word of the year is post-truth.
Zed Shaw is not stupid, but has a history of hyperbolic negativity that is, at times, difficult to distinguish from trolling even if it may not actually be intended as trolling.
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.
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
> '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.
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++.
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.
> In Python 2, you have one class, string, which is performing two different jobs.
What? Have you used Python 2? No: in Python 2, you have two classes; one is called "str" and represents a sequence of bytes, and one is called "unicode" and represents text. The former is used while interacting with network protocols and files, and the latter is what you use internally in your program: at the boundaries you use .decode and .encode to convert using character encodings. (BTW: Python 3 actually got this wrong for years, and even now I think it is only fixing the problem with a mitigation :/ filenames do not have an encoding: they should be of type "bytes", not of type "unicode", and Python 3 seriously shipped with an implementation of "list files in directory" which returned names as "unicode" and any names which failed to convert were just skipped.)
Then, Any text in your program should use a syntax u"" to indicate it is program text of type unicode. Sure: there are some really annoying implicit conversions in place that allow mistakes to be made, but WTF: they absolutely didn't need to rename "str" to "bytes" and "unicode" to "str" while simultaneously not only changing tons of other things in the language (the ability to pick and choose is amazing for porting) and making pointless related changes like removing the u"" syntax (which yes, I realize they added back later... years later... many many years too late). They should have just given me a way to "poison" str/unicode objects so they refuse to participate in implicit conversions, which would have let me find the corner cases in the libraries I use that are doing things wrong so I can report them to their maintainers and get them patched; after a couple years of people throwing .poison in a bunch of places users would have been ready to flip a VM-level "just don't convert them anymore".
As for renaming the classes, "bytes" should have been left as an alias for "str" (as it was/is "temporarily"/forever in Python 2.7), "str" should have generated a warning... I mean, "str" isn't even a good name :/... it's a silly three character abbreviation of a concept that is ambiguous in the minds of most developers already due to other languages, whether they be like C or JavaScript). They certainly had absolutely no good reason to get rid of the "unicode" type name (and this one still isn't back). The set of decisions they made were so annoying that even people who know what they are doing have to do a ton of fidgety and easily-broken work in a dynamically typed language where you are more than likely to just break something and not realize it until a month later.
Seriously: I've been programming in Python (2, not 3000) since 2007 as one of my primary programming languages; I do all of my web development in Python, for a website which is used around the world by millions of people and is not only itself translated into tons of languages (by both professionals and volunteers) but deals with tons of user-generated content that is accessed via tons of different channels (APIs from various websites, native network protocols, and tons of file formats as all the content indexing is also written by my, in Python), and dealing with these issues in Python 2 is simply a non-issue: in fact, I would say it is almost trivial (and in fact, the ways it tends to break in Python 2 are often quite similar to the way things break in Python 3, as it is easy to set up situations where the implicit conversions essentially fail).
Yes, I have used python 2 quite often, as well as python 3. Python 2 is sloppy in this regard. You can use a "str" to represent text, and it will work perfectly, so long as you stay within the ASCII character set, setting up hidden bugs later. Telling everybody to just use u"", while correct, sets up "" as something that looks correct, but isn't. In addition, suggesting that "str" is a sequence of bytes, rather than a string, is rather inappropriate. The documentation refers to them as strings, they are created in similar manner to strings in other languages, and they are generally accepted by library methods that set text properties.
I agree that there were some changes that were unnecessary, like the removal of the u"" syntax. That said, I think that the fundamental change, which was to have the thing named "string" be a string, was the right choice. Python has always been about having the obvious choice be the correct choice. Telling everybody that "quoted text" is not text runs counter to this.
> ... one is called "str" and represents a sequence of bytes ... The former is used while interacting with network protocols and files ... Python 3 actually got this wrong for years ...
2.7 does Unicode quite well. Not as well as it should, certainly, but arguably better than 3.3 did. I haven't played with anything since, and given the long history of this project going off the rails, I will require some serious convincing before I waste more time in it.
Yes I do multilingual string processing a LOT. I worked in SMT for about 3 years. Python 2.7 was the only practical option.
Python 3 does not fix the GIL. That would be enough to get me interested again.
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.
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.
>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?
> 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.
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.
Because Scala isn't nearly as popular as Perl was or Python is. I imagine losing some perceived status is less important to them than just doing the best they can to provide a good product and address people's needs.
Python is an interpreted language, so the comparison is meaningless.
It is cheap to deal with the ambiguity in the compiler using compile options. You could go the Java way and have separate class path (e.g. In PyPy, as CPython 2.x is dead).
But this does not allow you to mix and match code for older version anyway. Java was designed from start to allow this and it is why it's so stagnant.
Python is an interpreted language, so the comparison is meaningless.
Bash has no problem running old Bourne shell scripts from ancient history. Browsers have no problem running JavaScript from the mid-90s. I fail to see how being an interpreted language is a valid reason for breaking backwards compatibility.
I used C as an example of what happens when you don't change, not what happens when you do. C is used decades later with little change because of momentum and history, not because it's the pinnacle of computer languages.
C is not a good language. It was a good language, but that was a few decades ago. We've progressed past the point where C's shortcomings are excused by there not being alternatives that address those shortcomings while offering comparable features. At this point, we're just finally edging past of the local maxima created by C's exceptional popularity and the knock-on effects of that popularity, such as most operating systems (and all popular open source ones) being written in C.
What's replacing C? I can see languages like go/rust/crystal replacing C++ for application development, but what's producing stable binaries that other languages can consume in the same way the do C ones?
Rust can produce C compatible libraries. Go apparently can too. I suspect a little googling would show me that Nim and D can as well. I'm sure there are at least a few more.
Go can use C libraries, but AFAIK it cannot be compiled into a shared library to be used by a C program. Go needs control of the program flow to orchestrate its runtime (esp. the GC).
Nim can definitely produce C-compatible libraries, seeing how it compiles to C itself.
Interfacing D to C and C++ is failry easy as it was built with excellent C/C++ interop in mind. It's also compatible with C ABI and has limited compatibility with C++ ABI.
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++ :)
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.
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.
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?
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.
This is an excellent treatise on both the value of a computer science education and the importance of being sure that things you say in public aren't verifiably false.
"It's sad to watch Python destroy itself because it's such a great language, but that seems to be where things are headed."
The author has a point here. I've been programming Python for about 10 years now. Really concerned about the future of the language. Languages like Node and Go are progressing rapidly, but what's happening to Python? I used to complain about Node, but with the latest ES6/ES7 improvements it's actually pretty decent. The difference in usability between npm and pip is also huge.
Python is still my favorite language, but they really need to fix this part of the ecosystem. Maybe it's time to release Python 4 that has a clean upgrade path from 2 and enough language improvements to encourage users to adopt it?
You might just be being facetious, but in case you aren't, that's not true. The EMCAScript specification was based on JavaScript, not the other way around, and there are EMCAScript implementations that are not compatible with JavaScript (e.g. ActionScript, JScript). That is, JavaScript is one of many implementations of the EMCAScript standard, in and of itself it is not simply EMCAScript.
Nice try! ECMAScript is a standardized child of JavaScript, one with less warts and more awesome after lessons learned in javascript hell. ES6 will be nice.
Python's adoption is exploding in the data science / machine learning fields, I don't see Go or Node do the same, so I guess it depends on which field you are considering. Regarding web development specifically, then yes Python is not the latest hot-new-thing.
For the vast majority of a language users, the community and the libraries matter a lot more than the merits of the core language. Look at R. I'm not sure anyone would hold it up as a great core language. However, it is very successful and becoming more so, due to its awesome libraries and community.
numpy, scipy and matplotlib are really powerful. Go and Node don't have anything close to their capabilities.
Great things, IMHO. Now that the painful changes of 2 to 3 are done (or nearly so), recent releases have focused on incremental and steady progress. Take a look at the "What's New" documents:
There is a lot of great stuff there without ripping up the world and breaking all your programs. For example, the new compact dict implementation in 3.6 is a great improvement. All Python programs can potentially benefit from the memory use reduction. Bug fixes and improvements to library code are great.
The transition from 2.x to 3.x was not handled well. The core Python team should have focused much more on making transitioning code easier. Allowing code that can easily run in both 2.x and 3.x (with suitable shims like 'six') should have been a focus early on. Disallowing 'u' prefix on strings in 3.x is an example of a serious mistake. The argument of keeping 3.x pure was wrong. It is much more important to make transition easier rather than making 3.x extremely pure. That's something that C++ has got right, although maybe they went too far the other way.
My small contribution to transitioning 2.x to 3.x is "ppython". See my github repo:
Now that I've been programming in Python 3 for a few months, I find it pleasant. Writing programs that handle Unicode text correctly is easier. For small programs, it is easy to make them run under either Python 2 or 3.
One feature of Python 3 that I found really pleasantly useful recently (thank you SO :) ) was passing generators to the zip() function in a for loop, like:
for a, b in zip(generatorA(), generatorB()):
In Python 2 you have to import itertools to do this. I bring this up because I find examples like this all the time in Python 3 where core, modern language features like generators are more tightly integrated and easier to use. It's really a better version of the language and if you're starting fresh on a Python project you should do yourself a favor and use it.
Apart from his argument that Python 3 is not turing complete, which has been torn apart in the comments, can someone evaluate the other arguments. Are the other criticisms valid? If not, why?
I think some are valid criticisms, but not valid enough to throw your toys out of the pram.
> Not In Your Best Interests
I say what's in my best interest and py3 fixed a lot of issues for me. I'm happy with the upgrade and dropped py2 for new projects this year.
> No Working Translator
A flawless translator is simply not possible. 2to3 is the best effort idea. At some point you'll run into `def f(x): return x[0]` and without doing a full program static analysis you won't be able to say what's the right translation. You have to do it manually where needed.
> Difficult To Use Strings
I understand that the py2's "just works" strings are easier. But at the same time, having a non-ascii name I know that most applications "just work" simply because nobody actually tested them outside of ascii set. Py3 doesn't explode on encoding for fun - it basically says: you made an assumption that kind of worked so far by accident, but now you need to say explicitly what you want to do. I think it's a good thing, even if it takes people time to adjust.
> Core Libraries Not Updated
I don't even know what he means. This really needs an example, or it's just a meaningless rant.
> Purposefully Crippled 2to3 Translator
As above. Some things are just not possible to translate without knowing what the programmer meant. Some things in py2 strings happened to work a bit "by accident" and simply won't work in py3 for good reasons. For example py2 code:
In [1]: "abc".encode('ascii').encode('ascii')
Out[1]: 'abc'
It may look silly on one line, but there's lots of applications that relied on py2's "it just works" strings - and this what was effectively run at some point in the code logic.
Adoption is a real issue, but one that can be helped by actually using Python 3 (and encouraging others to use it), assuming you think the language is better. Big organizations have more clout here, for example Arch Linux uses Python 3 as the default Python interpreter.
The string/byte confusion is an issue for people who like to pretend that they're the same. They're not. A string can be represented by different byte streams depending on the encoding. That by itself tells you that they are not the same and should not be treated as the same thing. But we have many decades of conflating the two, and old habits die hard.
It's convenient to treat them as the same because IO deals with bytes and `write(some_string)` is easy. JavaScript's `"42" == 42` is just as easy, and just as wrong. The solution is both simple and easy: convert between strings and bytes at the IO interface. Explicit is better than implicit.
Alright. Point by point (although I'm considering both the beginner and "advanced" arguments for each point simultaneously):
> You Should Be Able to Run 2 and 3
That makes no sense. The whole point of versions is that they are different. Maybe he means 3 should be backwards compatible. That is potentially valid criticism. That said, AFAICT, the breaking changes are pretty reasonable [0][1]. Also, I'm not sure what world he is living in, but interop between Java and C/C++ through the JNI is not easy. As a math major I'm not sure what the "solid math" here is. I think it is ironic that the CLR is referenced here so extensively - it has made some pretty big breaking changes in the past (unlike Java, it decided to break backwards compatibility to have reified generics).
> No Working Translator
Translation is tough, _especially_ in languages like Python that don't have good static guarantees. The real problem here is probably that the code you want to produce with a translator should look as much like the original code when possible. That _is_ tough. The point is it isn't just what the program does in terms of inputs and outputs that you want to preserve. You still want it to look more or less the same.
> Difficult To Use Strings
This is not an incorrect point. I think Python 3 wanted to have both the performance of byte strings and utf8-by-default strings (finally!). The intention behind that seems reasonable. As a proponent of strong static typing, the error message he shows seems quite benign. That said, I understand how one might be unhappy about this.
> Core Libraries Not Updated
This may be the case, I'll defer to someone else. That said, this is yet another claim the author makes without much backing (this alone could be the subject of a blog post given the right backing). The quip about the Python community liking bad design seems a bit gratuitous.
The "Don't use it because people don't use it" argument bugs me. That's a valid argument when you're a CTO or Employee 0 picking a language that a thousand people will be using for fifteen years. Putting it on a tutorial site with good google juice, on the other hand, is a sad self-fulfilling prophecy.
There's good criticism here, but I can't help but feel the rest is mostly Zed flipping out.
Regarding 2to3 not being flawless: agree, could be better.
Regarding core libraries: agree, but the same problem exists on Python 2 (different core libraries have different levels of compatibility for taking string or unicode as arguments), so I don't see how this can be a recommendation against 3 specifically.
Regarding complaints about how many string interpolation methods there are: the `f` method relies on local scope (which is prone to introducing bugs), so it's actually pretty gimmicky compared to `.format` (which takes an explicit data structure as parameter). I would do the opposite and only teach `.format` to beginners since it leads to better code.
> Regarding 2to3 not being flawless: agree, could be better.
The thing to remember though is that 2to3 will never be flawless. Since the underlying representation of some things has been split into different types, it simply impossible to automatically fix some code.
For example a function returning the first letter read from a file object is going to be completely different and more explicit in py3 than it was in py2. And the end result it better. You have to fix some code now - tough.
280 comments
[ 3.3 ms ] story [ 284 ms ] threadI stopped there.
[1] https://en.wikipedia.org/wiki/Turing_completeness
Then I read more for laughs.
I kind of feel like I could fix py2to3 if I have a sed and awk layer in there.. maybe a fun project.
I like what you said about self-obsessed project. It's clear that you have a very well reasoned position, not just opinion. What you say makes irrefutable sense.
I stopped there.
I am unsure when the idea of python3 (first as python 3000) came to general knowledge, but it must have been some time between 2000 and 2004. Then python3 was published in 2008.
So the time between obsoleting the old version, before the new version was available, was notably shorter with python.
There's also a good chance I'm confusing perl and parrot.
At least that's the conclusion that is repeatedly forced upon C, no matter what the argument is.
But people talking about Turing completeness in a real programming language (usually in the form of "x is Turing complete, therefore you couldn't ask for more") almost always haven't got a clue.
http://www.madore.org/~david/programs/unlambda/#what_is
As such, I think it represents one of the most enlightening esoteric languages out there together with Brainfuck.
"Garbage collection is simulating a computer with an infinite amount of memory". https://blogs.msdn.microsoft.com/oldnewthing/20100809-00/?p=...
We both agree, I'm just using this as a pretext to share this intriguing piece of knowledge. I find the concept much more intuitive than "getting back unused memory".
Especially when you look at the 90% memory usage on your OS, it still make sense with the "infinite memory simulation" definition.
There is a fun quote about that...
"There are those who tell us that any choice from among theoretically-equivalent alternatives is merely a question of taste. These are the people who bring up the Strong Church-Turing Thesis in discussions of programming languages meant for use by humans. They are malicious idiots. The only punishment which could stand a chance at reforming these miscreants into decent people would be a year or two at hard labor. And not just any kind of hard labor: specifically, carrying out long division using Roman numerals. A merciful tyrant would give these wretches the option of a firing squad. Those among these criminals against mathematics who prove unrepentant in their final hours would be asked to prove the Turing-equivalence of a spoon to a shovel as they dig their graves."
-- Stanislav Datskovskiy
I'll say this, at Pycon 2016 I attended some dev sprints/hackathons with the python 3 developers. Python 2 is no where on their radar, its dead. They have moved on. There will be no additional compatibility layers or any of that. All of the mainline libraries that everyone uses (django, sql alchemy, etc ) have moved on to python 3. If you haven't, you should to.
py3.3 support is at alpha level. py3.5 support is in the pipeline and already available for testing. It's unlikely they'll do any effort that's targeting py2 specifically anymore.
No. The rest of the community is much better. In fact, his behavior is an aberration.
> Python 3 has been purposefully crippled to prevent Python 2's execution alongside Python 3 for someone's professional or ideological gain.
I can't tell if Zed's referring to python3 doing a fork()/exec() of a python2 not working correctly or if he wants/expects some kind of inter-language import or "linking" among files written for respective language versions. What's he getting at?
Is there really something that prevents you from executing python2 at the same time as python3? (I tried a simple program "os.system('python3 -c \'print ("hello")\'')" and it worked just fine.
N.B.: I haven't worked with Python so if you can actually do this somehow let me just say that that's not the impression the article left me with.
It's extremely badly conveyed but that's what I got out of it by keeping reading.
I do disagree with him on all the rest though, especially strings. It didn't "just work" before, it failed silently and who knows how much disaster he or his readers have caused because of it. Now at least you can't be wrong anymore. For a language heavily used on the web, it's hugely important to understand where your strings are coming from and where they're going to, and how.
Besides, Python is not a frigging "beginners language". Just because Python (and admittedly especially Python 2) is generally easy to grasp as a first language doesn't mean it's its purpose, nor should it constrain itself toward this goal. It's used in a million of different areas, including pretty sensitive ones. It's now become a more mature language, reaching for exactitude and consistency. Just because Zac no longer has an easy toy language to point script kiddies to so they can "learn to program" by reading one website doesn't mean Python is to blame.
I hope to continue leveraging my investment in learning python by using it for a long time. So far I haven't been forced to use Python 3. I've tried a few times but always found it easier to just go back to python (2.7).
I figure eventually I have to use Python 3 but at this point, my life has been fine without upgrading to python3.
I switched around 3.1, though granted I was still a novice programmer then and didn't have to port any legacy code. I had so many issues with Unicode in Python 2 (some may have been my own ignorance at the time, but with 3 a lot of those issues magically disappeared). Since text processing / NLP is my main focus, it was an easy decision to switch.
You're essentially giving up great features like async keyword and proper encoding handling getting nothing in return. The few libraries that are still Python 2 only should be ignored.
... Not only is this blatantly false, but the author acknowledges it as such and seems to think that it is still OK to write this sort of sentence. Backing a pure falsehood with anecdotal support from "actual Python project developers" does nothing to change its veracity. I can't respect anything else in this article after seeing this kind of sensationalism.
Perhaps the author doesn't understand Turing-completion (I'll give the author the benefit of the doubt), but even if so it's inexcusable to throw around this sort of technical language this casually.
I'm confused by this statement. I can start a python2 interpreter, background it, then start a python3 interpreter. Is there some other area that they inhibit each other in?
Python 3 was released in 2008. Eight years ago.
https://web.archive.org/web/20080305002455/http://www.zedsha...
[0] http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto
"I’ll add one more thing to the people reading this: I mean business when I say I’ll take anyone on who wants to fight me. You think you can take me, I’ll pay to rent a boxing ring and beat your fucking ass legally."
P.S: I'm really sorry Java guys, I know Java isn't going to die, atleast not for another 100 years, but since I don't like it much, I'm putting it in the list here.
The print statement however is not valid Python 3 :).
print(f"Howdy {x}")
It's a new python 3.6 feature called f-strings/string interpolation
https://docs.python.org/3.6/reference/lexical_analysis.html#...
That said in python3 print is a function not a statement and requires parenthesis so he still has a typo.
There are parts of Python that look like it wants programmers do low level compiler job and I can't understand why. This is one of them. Python can do %s string interpolation without some s'' s-strings so I wonder why it needs this f-string thing. Many languages can do string interpolation without having developers babysitting the interpreter. In 2016 we have the CPUs to make it happen the other way around.
What does this even mean?
But who knows, his actual argument is absolute mess
Funny how many haven't seen it and are arguing pointlessly.
I just checked his twitter to make sure I'm right. He's clearly joking.
https://mobile.twitter.com/zedshaw
It can; arguing it can't would be an 'argument from fallacy', itself a fallacy.
Put another way, I can make up a totally absurd, incorrect argument that the sky is blue, but the sky is still blue. I can also make up a totally absurd, incorrect argument that the sky is green, but it isn't. An argument that doesn't hold water doesn't say anything useful about the conclusion either way.
If Guido had said "2 is done. Deal with it, fuck you." a long time ago, this wouldn't be an issue today. Breaking language changes are nothing new, but mgmt this weak is.
Hell, I primarily work in C# and I LOVE the breaking changes of .NET Core and Standard. They tore the garbage out, and it runs on Linux. Awesome!
As I mentioned in another thread the OED's word of the year is post-truth.
Zed is clearly a modern man.
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.
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.
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...
Yes it does:
https://stackoverflow.com/a/6402166/31667
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.
What? Have you used Python 2? No: in Python 2, you have two classes; one is called "str" and represents a sequence of bytes, and one is called "unicode" and represents text. The former is used while interacting with network protocols and files, and the latter is what you use internally in your program: at the boundaries you use .decode and .encode to convert using character encodings. (BTW: Python 3 actually got this wrong for years, and even now I think it is only fixing the problem with a mitigation :/ filenames do not have an encoding: they should be of type "bytes", not of type "unicode", and Python 3 seriously shipped with an implementation of "list files in directory" which returned names as "unicode" and any names which failed to convert were just skipped.)
Then, Any text in your program should use a syntax u"" to indicate it is program text of type unicode. Sure: there are some really annoying implicit conversions in place that allow mistakes to be made, but WTF: they absolutely didn't need to rename "str" to "bytes" and "unicode" to "str" while simultaneously not only changing tons of other things in the language (the ability to pick and choose is amazing for porting) and making pointless related changes like removing the u"" syntax (which yes, I realize they added back later... years later... many many years too late). They should have just given me a way to "poison" str/unicode objects so they refuse to participate in implicit conversions, which would have let me find the corner cases in the libraries I use that are doing things wrong so I can report them to their maintainers and get them patched; after a couple years of people throwing .poison in a bunch of places users would have been ready to flip a VM-level "just don't convert them anymore".
As for renaming the classes, "bytes" should have been left as an alias for "str" (as it was/is "temporarily"/forever in Python 2.7), "str" should have generated a warning... I mean, "str" isn't even a good name :/... it's a silly three character abbreviation of a concept that is ambiguous in the minds of most developers already due to other languages, whether they be like C or JavaScript). They certainly had absolutely no good reason to get rid of the "unicode" type name (and this one still isn't back). The set of decisions they made were so annoying that even people who know what they are doing have to do a ton of fidgety and easily-broken work in a dynamically typed language where you are more than likely to just break something and not realize it until a month later.
Seriously: I've been programming in Python (2, not 3000) since 2007 as one of my primary programming languages; I do all of my web development in Python, for a website which is used around the world by millions of people and is not only itself translated into tons of languages (by both professionals and volunteers) but deals with tons of user-generated content that is accessed via tons of different channels (APIs from various websites, native network protocols, and tons of file formats as all the content indexing is also written by my, in Python), and dealing with these issues in Python 2 is simply a non-issue: in fact, I would say it is almost trivial (and in fact, the ways it tends to break in Python 2 are often quite similar to the way things break in Python 3, as it is easy to set up situations where the implicit conversions essentially fail).
I agree that there were some changes that were unnecessary, like the removal of the u"" syntax. That said, I think that the fundamental change, which was to have the thing named "string" be a string, was the right choice. Python has always been about having the obvious choice be the correct choice. Telling everybody that "quoted text" is not text runs counter to this.
> ... one is called "str" and represents a sequence of bytes ... The former is used while interacting with network protocols and files ... Python 3 actually got this wrong for years ...
Actually some Japanese have suffered from this wrong design of Python 3. If you read Japanese, please see http://www.oki-osk.jp/esc/python/upload-cgi/v2.html#3
Yes I do multilingual string processing a LOT. I worked in SMT for about 3 years. Python 2.7 was the only practical option.
Python 3 does not fix the GIL. That would be enough to get me interested again.
As do most corporations. If you want a job in Python, you had best know 2.7.
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.
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?
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.
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.
Why do you single out Scala as being particularly different to Python and Perl?
But is there any C11 compiler out there that will refuse to compile C99?
It is cheap to deal with the ambiguity in the compiler using compile options. You could go the Java way and have separate class path (e.g. In PyPy, as CPython 2.x is dead).
But this does not allow you to mix and match code for older version anyway. Java was designed from start to allow this and it is why it's so stagnant.
Bash has no problem running old Bourne shell scripts from ancient history. Browsers have no problem running JavaScript from the mid-90s. I fail to see how being an interpreted language is a valid reason for breaking backwards compatibility.
C is not a good language. It was a good language, but that was a few decades ago. We've progressed past the point where C's shortcomings are excused by there not being alternatives that address those shortcomings while offering comparable features. At this point, we're just finally edging past of the local maxima created by C's exceptional popularity and the knock-on effects of that popularity, such as most operating systems (and all popular open source ones) being written in C.
Nim can definitely produce C-compatible libraries, seeing how it compiles to C itself.
Go 1.5 added support for this.
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++ :)
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&res...
[1] http://www.deeplearning.net/software/theano/install.html
[2] https://www.tensorflow.org/versions/r0.11/get_started/os_set...
[3] https://keras.io/#you-have-just-found-keras
[4] https://lasagne.readthedocs.io/en/latest/user/installation.h...
About the only thing that is dead like that seems to be Enthought project for drawing and creating UI for graphs.
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.
The author has a point here. I've been programming Python for about 10 years now. Really concerned about the future of the language. Languages like Node and Go are progressing rapidly, but what's happening to Python? I used to complain about Node, but with the latest ES6/ES7 improvements it's actually pretty decent. The difference in usability between npm and pip is also huge.
Python is still my favorite language, but they really need to fix this part of the ecosystem. Maybe it's time to release Python 4 that has a clean upgrade path from 2 and enough language improvements to encourage users to adopt it?
I've done Python about as long as you but also like Golang for things Python is awful at.
The OP was basically talking about the JVM as if it was a language.
*edit typo
numpy, scipy and matplotlib are really powerful. Go and Node don't have anything close to their capabilities.
Great things, IMHO. Now that the painful changes of 2 to 3 are done (or nearly so), recent releases have focused on incremental and steady progress. Take a look at the "What's New" documents:
https://docs.python.org/3.6/whatsnew/3.6.html https://docs.python.org/3/whatsnew/3.5.html
There is a lot of great stuff there without ripping up the world and breaking all your programs. For example, the new compact dict implementation in 3.6 is a great improvement. All Python programs can potentially benefit from the memory use reduction. Bug fixes and improvements to library code are great.
The transition from 2.x to 3.x was not handled well. The core Python team should have focused much more on making transitioning code easier. Allowing code that can easily run in both 2.x and 3.x (with suitable shims like 'six') should have been a focus early on. Disallowing 'u' prefix on strings in 3.x is an example of a serious mistake. The argument of keeping 3.x pure was wrong. It is much more important to make transition easier rather than making 3.x extremely pure. That's something that C++ has got right, although maybe they went too far the other way.
My small contribution to transitioning 2.x to 3.x is "ppython". See my github repo:
https://github.com/nascheme/ppython
Now that I've been programming in Python 3 for a few months, I find it pleasant. Writing programs that handle Unicode text correctly is easier. For small programs, it is easy to make them run under either Python 2 or 3.
for a, b in zip(generatorA(), generatorB()):
In Python 2 you have to import itertools to do this. I bring this up because I find examples like this all the time in Python 3 where core, modern language features like generators are more tightly integrated and easier to use. It's really a better version of the language and if you're starting fresh on a Python project you should do yourself a favor and use it.
https://repl.it/E5v6/2
Try this in py2: https://repl.it/E5vd/0
Uhhh..? A more trendy language? Are we really saying that Elixir is more stable than Python?
EDIT: https://learnpythonthehardway.org/book/ex0.html
Wow - python 2.5.1. He even does not update to 2.7.
> Not In Your Best Interests
I say what's in my best interest and py3 fixed a lot of issues for me. I'm happy with the upgrade and dropped py2 for new projects this year.
> No Working Translator
A flawless translator is simply not possible. 2to3 is the best effort idea. At some point you'll run into `def f(x): return x[0]` and without doing a full program static analysis you won't be able to say what's the right translation. You have to do it manually where needed.
> Difficult To Use Strings
I understand that the py2's "just works" strings are easier. But at the same time, having a non-ascii name I know that most applications "just work" simply because nobody actually tested them outside of ascii set. Py3 doesn't explode on encoding for fun - it basically says: you made an assumption that kind of worked so far by accident, but now you need to say explicitly what you want to do. I think it's a good thing, even if it takes people time to adjust.
> Core Libraries Not Updated
I don't even know what he means. This really needs an example, or it's just a meaningless rant.
> Purposefully Crippled 2to3 Translator
As above. Some things are just not possible to translate without knowing what the programmer meant. Some things in py2 strings happened to work a bit "by accident" and simply won't work in py3 for good reasons. For example py2 code:
It may look silly on one line, but there's lots of applications that relied on py2's "it just works" strings - and this what was effectively run at some point in the code logic.The string/byte confusion is an issue for people who like to pretend that they're the same. They're not. A string can be represented by different byte streams depending on the encoding. That by itself tells you that they are not the same and should not be treated as the same thing. But we have many decades of conflating the two, and old habits die hard.
It's convenient to treat them as the same because IO deals with bytes and `write(some_string)` is easy. JavaScript's `"42" == 42` is just as easy, and just as wrong. The solution is both simple and easy: convert between strings and bytes at the IO interface. Explicit is better than implicit.
> You Should Be Able to Run 2 and 3
That makes no sense. The whole point of versions is that they are different. Maybe he means 3 should be backwards compatible. That is potentially valid criticism. That said, AFAICT, the breaking changes are pretty reasonable [0][1]. Also, I'm not sure what world he is living in, but interop between Java and C/C++ through the JNI is not easy. As a math major I'm not sure what the "solid math" here is. I think it is ironic that the CLR is referenced here so extensively - it has made some pretty big breaking changes in the past (unlike Java, it decided to break backwards compatibility to have reified generics).
> No Working Translator
Translation is tough, _especially_ in languages like Python that don't have good static guarantees. The real problem here is probably that the code you want to produce with a translator should look as much like the original code when possible. That _is_ tough. The point is it isn't just what the program does in terms of inputs and outputs that you want to preserve. You still want it to look more or less the same.
> Difficult To Use Strings
This is not an incorrect point. I think Python 3 wanted to have both the performance of byte strings and utf8-by-default strings (finally!). The intention behind that seems reasonable. As a proponent of strong static typing, the error message he shows seems quite benign. That said, I understand how one might be unhappy about this.
> Core Libraries Not Updated
This may be the case, I'll defer to someone else. That said, this is yet another claim the author makes without much backing (this alone could be the subject of a blog post given the right backing). The quip about the Python community liking bad design seems a bit gratuitous.
[0]: https://docs.python.org/3/whatsnew/3.0.html [1]: http://sebastianraschka.com/Articles/2014_python_2_3_key_dif...
Regarding 2to3 not being flawless: agree, could be better.
Regarding core libraries: agree, but the same problem exists on Python 2 (different core libraries have different levels of compatibility for taking string or unicode as arguments), so I don't see how this can be a recommendation against 3 specifically.
Regarding new string types and handling, this has been discussed over and over again everywhere on the web, and boils down to people freaking out at unicode by default. This one does a good job explaining everything: http://www.diveintopython3.net/strings.html and this one does a good job at showing what you get w/ Py3 (not limited to new string types): https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-...
Regarding complaints about how many string interpolation methods there are: the `f` method relies on local scope (which is prone to introducing bugs), so it's actually pretty gimmicky compared to `.format` (which takes an explicit data structure as parameter). I would do the opposite and only teach `.format` to beginners since it leads to better code.
Regarding Turing completeness: fun.
The thing to remember though is that 2to3 will never be flawless. Since the underlying representation of some things has been split into different types, it simply impossible to automatically fix some code.
For example a function returning the first letter read from a file object is going to be completely different and more explicit in py3 than it was in py2. And the end result it better. You have to fix some code now - tough.