Saturday, May 26, 2018

Please do not break my code

How long should code last?
I started coding in Java back in the last millennium.  I fully expect that code I wrote back then will still work on a modern JVM, indeed some it may still be running today.  It would probably run faster and better than it did when it was first written given the improvements in hardware, JIT optimizations and garbage collection.

For the last year or so I have been writing in Python ... Python 2 to be precise.  I have no hope that in 20 years any of the code I am writing today will be runnable yet alone running.  Python 3.0 was released December 3, 2008 ... almost a decade ago.  Why am I using Python 2 in 2018?

If we look at Python Versions Used in Commercial Projects in 2017 we see that I am not alone.  63.7% of commercial Python projects are still using 2.7.   If Python 3 is better (which it is) why are so many projects still not using it after so many years?

To deprecate or to break

Often language designers and library maintainers are faced with a difficult decision of deprecating code or introducing breaking changes.  There are large costs to either decision.

Back in 1996 Java introduced the deprecated tag as a way to mark code as:
  • the old API is insecure, buggy, or highly inefficient
  • the old API is going away in a future release
  • the old API encourages very bad coding practices
Fortunately, the second reason for deprecating was never really implemented.  Nothing deprecated has ever been removed from the language.  Nothing.  

Whoever made the decision to not remove deprecated code should be given a Nobel prize.

This decision means the burden of the deprecated code remains with the owner of the code.  Each release will need to test and validate code they would rather not have to maintain.  This is no small cost I am sure.

Compare this with the Python decision to make breaking changes moving from Python 2 to Python 3.  By making this decision, they try to move the on-going cost maintaining "dead" code to a one-time cost distributed across all projects using Python.  

The cost for just one company (the one I work for) to move to Python 3 will be enormous.  Because there are known breaking changes, all code will need to be treated as unreliable and have to be proven to be working correctly.  This is not just code we have written but any library we have included as well.  This represents hundreds or thousands of man-hours and increased risk ... ALL FOR NO BENEFIT.  If all goes well after weeks or months of effort, we will end up with the exact same functionality we started with.  Or, we could focus on what keeps us in business.  Hence the reason we are still using Python 2

Which means that the effort to distribute the cost of the breaking changes to everyone else has not really worked out.  2/3 of projects are still using the old code after 10 years.  The one time cost has becoming an on-going problem with no end in sight.  There are no winners in this debacle, just a fractured community.

Don't get me wrong, I like Python.  It is unfortunate that this difficult decision resulted in a situation that detracts from the usefulness of the language.

How long should code last?  As long as it is useful, not just until some language or library owner decides it is better to break it.  Please do not break my code.


No comments: