9 ms·
The double standard when it comes to Python is mindblowing. No other language could have gotten away with such ridiculous fragmentation and perf regression for
by VeejayRampay 9y ago
The double standard when it comes to Python is mindblowing. No other language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time.
- ggm 9y agoPerl6
- mateuszf 9y agoPerl6 is not as widely used as Python 3. Also it's practically a new language in comparison to Perl5.
- BjoernKW 9y agoWell, they didn't really get away with it. Perl isn't as widely used as it used to be. Besides, in spite of the name Perl6 isn't compatible with Perl5 but rather a completely new language.
- labster 9y agoPerl 6 is a completely new language, but that doesn't mean it's incompatible. Inline::Perl5 provides a rather extensive compatibility layer with Perl 5: https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5
- peteretep 9y agoBy this logic, Perl is also compatible with the many other languages for which there are Inline:: modules.
- raiph 9y agoThe Perl 6 Inline::Perl5 automatically maps Perl 5's syntax, object system semantics, exceptions, etc. to Perl 6's so that Perl 6 users don't in principle have to know about Perl 5, just the logical API of any used module/library/function. I don't think the Perl 5 inlines do this.
- mjburgess 9y agoThey didnt really "get away with it". But as far as Oracle, for example,doing something similar -- yes, open source languages get more of a pass. Being an open community effort gives you a free-pass to make mistakes because you're methodologically sincere. Decisions are made by, and on behalf of, those who use the systems. Having proprietary interests means you're methodologically insincere: mostly, you sell decisions for the developer but they are mostly for the company.
- oblio 9y agoAlso the tech upgrade is free in terms of software license costs. Yes, those are generally dwarfed by time investments for tests, but still.
- sorisos 9y agoMany languages seem to suffer from legacy support. C++ and PHP for example. The double standard might be the only way to avoid this!?
- pjc50 9y agoThe legacy support is a benefit for people who are still using it. The lesson from both Perl and Python is clear: you cannot remove language features - if you do you're creating a new language which has to start from zero in adoption.
- b2gills 8y agoPerl 6 removes very few language features. About the only notable ones I can think of is fork and format. Since Perl 6 has built-in multithreading, fork is not needed. And hardly anyone uses format anymore (it is great for directly printing to a line printer). What Perl 6 did is change the syntax for various features of Perl 5; while adding a lot of new features.
- Y_Y 9y agoNot to mention the loss of tuple unpacking in function signatures. Even if i felt morally wrong about it, for the last few years I've been writing python2 with a few `from __future__`s at the top since it was fastest and most featureful and had all the libraries.
- ChrisSD 9y agoI'm not sure that tuple unpacking in function signatures is any great loss. It's a feature I hardly ever saw used and if you do need to unpack an argument then you can do so in the first line of the function's code.
- dx034 9y agoI saw it used a lot and it caused hours of rewrites to get libraries python3 ready. It's one of those things where I wonder why they didn't just depreciate it for another few iterations, allowing scripts to be changed over time.
- ChrisSD 9y agoThe 2to3 tool will rewrite it automatically. It's not something that requires manual intervention.
- dralley 9y agoOh ho ho, it is _not_ that simple. Any code with a lot of assumptions about text encoding or integer division is going to be terribly broken after 2to3. It very much does require manual intervention unless you're doing very simple scripts.
- ChrisSD 9y agoSure but the 2to3 tool allows you to run the tuple_params fixer on its own. Text encoding and integer division are separate issues and have nothing to do with unpacking tuples in function arguments. My point in this conversation has been that this feature doesn't require manual rewrites. And I'd add that in any case the deprecation period for python 2 will have been 12 years once Python 2 reaches EOL. That's plenty of time to update a code base.
- nothrabannosir 9y agoDouble standards by whom?? Every other article or comment I’ve read since basically py3+1y has been incredibly negative about it. The only positive news about Python, recently, seems from people who were not around since the py2 days. Data science is where it’s at now, but it used to be massive and ubiquitous. Golang came at a time where public perception of Python was down the drain, and ate a big chunk of its lunch.
- samastur 9y agoI've been around since ~1.5 and have no idea what you are talking about. I suspect our perception is very much coloured by where and whom you are hanging out with. Agree that there was never a shortage of negative articles about py2/py3 transition. Fairly certain Golang success was down to its advantages more than Python's perception who's use has grown through all this time.
- goatlover 9y ago> and ate a big chunk of its lunch Pretty sure that's not true. Golang might have taken some from Python web frameworks or command line tools, but that's about it. Python's popularity in scientific computing has only grown over time, and that encompasses a lot of fields and users, not just data science.
- ianamartin 9y agoMy interpretation of the usage share is that Golang ate a bunch of lunch that would've otherwise gone to Python. That is, people moving from other languages (Perl, PhP) to something else for various reasons. Absent Go, I suspect many current Gophers would've landed on Python. So in a sense, Python lost people to Go. But I've never seen anything to indicate that there was a large migration from Python to Go, and certainly not because of 2 to 3 or public perception--whatever that means in the context of a programming language. Python 2 is still the mainstay for Data Scientists. I've seen more resistance to moving to 3 there than almost anywhere. Which is pretty funny because it's the easiest code to port assuming your data science libs support 3 (and all the big ones do.) I think it's more accurate to say that Go ended up with some of Python's potential mindshare, not that it stole a significant amount of existing mindshare.
- mhd 9y agoWasn't there a big brouhaha over the change from VB6 to VB.Net? The big difference there is that if it's ordained from your corporate overlords, you have little choice, whereas you feel like you've got a bigger right to complain when it's "just" coming from the BDFL.
- umanwizard 9y agoVB.NET is a totally new language almost unrelated to VB6. That’s like talking about C vs C++, not py2 vs py3.
- toyg 9y agoCalling it a “New language” flatters Vb.net. In reality, it was a “marketing compatibility shim” on top of C# to help VB developers acclimatise to the CLR.
- michaelt 9y agoAs VB6 is compiled, you don't need your users to have a particular interpreter version installed.
- ceronman 9y agoWhat do you mean by double standard? Everyone in the community, including the core developers, acknowledge that the 2 to 3 story was full of mistakes. They have promised not to make it again. And they took some actions to remedy the problems, and that's why Python 3 is finally succeeding. I recommend this presentation by Victor Stinner at FOSDEM 2018 which talks about it: https://fosdem.org/2018/schedule/event/python3/ https://fosdem.org/2018/schedule/event/python3/
- VeejayRampay 9y agoThe double standard is that people still stick to Python despite those problems. If we're being honest and all conspiracy aside, imagine the same story for Ruby (a very similar language in terms of capability, features and performance), everyone would be laughing at them and the language would be pulling a Perl right now.
- stealthcat 9y agoRuby took off because of Rails. Rails' convention over configuration defies Ruby's flexible nature. It feels more like Python. People prefer dumb unambiguous code over clever code. That's why Python and Rails succeeded
- ComputerGuru 9y ago“Dumb, unambiguous code” does not rely on magic conventions that change with the whim of the framework developer.
- toyg 9y agoThat massive chip on your shoulder is weighing you down. If you really think something like that is happening (big if - I’ve gone through so many py3 flames...), the only answer is: because people love the language SO DAMN MUCH that they will overlook its warts. And the next logical step would be to find out how an independent research project, staffed mostly by volunteers and without a marketing budget of any sort (and not running in every browser nor shipping preinstalled on the most popular operating system), ended up with this sort of mindshare. There might be some good lessons there.
- hyperpallium 9y agoI think it's the opposite. When other languages make incompatible changes, they have serious problems (e.g perl6). Previous versions of python were back-compatible. Java versions stress back-compatibility. I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Python has done everything possible to avoid this fate, by maintaining 2.7. And I'm not even convinced python has gotten away with yet (e.g. kalite, offline khan academy, needs 2.7). RHEL may end up reversing this. Give it another ten years! Amd the Enterprize is the most back-compatible thing you've ever seen. This change is going to break lots of code, and they will reverse or lose customers.
- Xylakant 9y ago> When other languages make incompatible changes, they have serious problems (e.g perl6). Counter-example: The ruby 1.8 -> 1.9 -> 2.0 upgrade path. 1.9 introduced the whole encoding system, which was a major update at the time. It did break a lot of libraries that handled strings. Still, the change went over fairly quickly, partly because major players in the ruby world (rails) adopted the change. The update also brought clear benefits and it was clearly marked that 1.8 was going to go out of support. There are still some stragglers (centos 6, I'm looking in your direction), but it's clearly accepted that ruby 2.x is the standard that you should be writing code for.
- Steeeve 9y ago> Java versions stress back-compatibility. You reminded me of the java version incompatibility nightmares that once littered the enterprise landscape. If they do that now, it's because their history includes perhaps the worst set of incompatibility jumps of any popular language.
- irishsultan 9y ago> I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Ruby qualifies, I'd say. From 1.8 -> 1.9 there were syntax changes, changes to how strings worked and so on. Code written for 1.8 would not in general work on 1.9 and the other way around. While it was possible (sometimes with some extra if statements) to write code that worked on both versions I would definitely call it an incompatible, code-breaking upgrade.
- jnwatson 9y agoI guess you haven’t looked at Swift. All 4 major versions are very incompatible.
- deleted 9y ago[deleted]
- imtringued 9y agoIt's still a young language and doesn't have as much legacy codebases as python.
- tjalfi 9y agoXcode also has tooling support that will handle a lot of the language conversion for you.
- est 9y ago> No other living language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time FTFY. Just think about Perl6, Lua5.3 and VB.NET I am pretty sure somewhere in this world a miserable soul has to maintain a Ruby1.8 codebase.
- canofmoi 9y agoQuite the opposite. Python had deep problems that could simply not be fixed without BC breaks. The decision was made, and in hindsight it was the correct decision by Guido and other core devs. Look at PHP, and look what a total cluster of madness the language has become.
- oblio 9y agoI think Python 3 was not brave enough, to be honest, to future proof Python: * an optional type system without hacks was not introduced (types in comments, really?) * the GIL was not removed or at least a solid parallelism story was not included, one that would allow Python to use all cores on a system while sharing, if needed, memory * no true performance improving changes were made; by this I mean stuff that improve performance by an order of magnitude; Python is still way too dynamic and this basically sunk Google's Unladen Swallow and Dropbox's Pyston, at least in terms of worldwide adoption I say this because I'm a bit worried that long term Python has locked itself into a corner where it will keep getting pushed into as the other languages develop a better developer UX. Python was a bit lucky to catch the ML train but who knows how long this will last. And Go, Kotlin, Typescript, Swift, Julia, Rust even are improving their ergonomics and edging towards Python's core competency.
- jononor 9y agoSince Python 3.5 (3 years ago) type hints are part of the core syntax. Don't need to put them in comments. https://www.python.org/dev/peps/pep-0484/#type-definition-syntax https://www.python.org/dev/peps/pep-0484/#type-definition-sy...
- pbalau 9y agoPhp3 and php4? Php4 and 5? Then I've lost contact with pure php