(no title)
Kednicma | 5 years ago
First, the excellent readability leads directly into hard-to-read code structures. This might seem paradoxical but Dijkstra insisted that the same thing happened in FORTRAN, and I'm willing to defer to his instinct that there's something about the "shut up and calculate" approach that physicists have which causes a predilection for both FORTRAN and Python.
Second, Python 2 to Python 3 was horrible, and created political problems which hadn't existed before. Now, at the end of the transition, we can see how badly it was managed; Python 2 could have been retrofitted with nearly every breaking change and it would have been lower-friction. Instead, there's now millions of lines of rotting Python 2 code which will never be updated again. Curiously, this happened in the FORTRAN world too; I wasn't around for it, but FORTRAN 77 was so popular compared to future revisions and standardizations that it fractured the FORTRAN community.
nendroid|5 years ago
This doesn't make any logical sense. Your saying take the breaking changes in python 3 and put it into python 2? That's just a version number. You can call it version 2.999999.8 and do all the changes in there and the outcome is identical.
No. Every breaking change must have a downstream change in every library that uses that breaking change. That's the reality of breaking changes. No way around it.
Tell me of such a migration as huge as python 2->3 that was as successful. For sure there were huge problems along the way and it took forever. However I have heard of very very few migrations in the open source world that ended up with an outcome as successful as python.
>First, the excellent readability leads directly into hard-to-read code structures.
I don't agree with this either. You refer to fortran but most programmers here haven't used it so you'll have to provide an example for readers to see your point.
Kednicma|5 years ago
* Perl 5 to Perl 6: So disastrous that they rolled back and Perl 6 is now known as Raku
* PHP5 to PHP7: Burn my eyes out, please! But of course PHP has unique user pressures, and a monoculture helps a lot
* Python 2.4 to Python 2.7: Done in several stages, including deprecation of syntax, rolling out of new keywords, introduction of backwards-compatible objects and classes, and improvements to various semantic corner cases
* Haskell 98 to Haskell 2010: GHC dominated the ecosystem and now Haskell 98 is only known for being associated with Hugs, which knows nothing newer
* C++03 and earlier to C++11: Failed to deprecate enough stuff, but did successfully establish a permanent 3yr release cadence
* C99 to C11: Aside from the whole Microsoft deal, this was perfect; unfortunately Microsoft's platforms are common in the wild
Now consider how many Python 3 features ended up backported to Python 2 [0] and how divisive the upgrade needed to be in the end.
On readability, you'll just have to trust me that when Python gets to millions of lines of code per application, the organization of modules into packages becomes obligatory; the module-to-module barrier isn't expressive enough to support all of the readable syntax that people want to use for composing objects. If you want a FORTRAN example, look at Cephes [1], a C library partially ported from FORTRAN. The readability is terrible, the factoring is terrible, and it cannot be improved because FORTRAN lacked the abstractive power necessary for higher-order factoring, and so does C. Compare and contrast with Numpy [2], a popular numeric library for Python which is implemented in (punchline!) FORTRAN and C.
[0] https://docs.python.org/2/whatsnew/2.7.html#python-3-1-featu...
[1] https://github.com/jeremybarnes/cephes
[2] https://github.com/numpy/numpy