5 ms·

Most people who use a language are actually working on code that existed before yesterday. I work on a codebase that was written in python 2, and when we looked

by rsj_hn 9y ago

Most people who use a language are actually working on code that existed before yesterday. I work on a codebase that was written in python 2, and when we looked at the cost of upgrading it to python 3 versus adding new features, it was a no brainer. I have no desire to switch to python 3, nor do I anticipate ever doing so, at least for the projects I'm working on now. If you are maintaining a large or important codebase rather than working as a hobbyist or independent contractor, then there is nothing wrong with using older languages/platforms, especially if they are stable and well tested. Avoiding surprises or breakage is generally a lot more important to you than getting a cool new list comprehension facility. Actually, stability of the language is something to be desired, as there is a cognitive cost to having different portions of the project use different language constructs. In terms of python 2 not being supported in the future, if we are forced to stop using python 2, we'll probably need to switch the project over to Java. Not something I'm looking forward to, but at least the java community doesn't force developers to rewrite their source code when a new JVM comes out. There were some examples of older bytecode not working in newer JVMs, but as long as you had the original sources you could always compile to the newer bytecode. Personally, I've grabbed jars from 2005 and used them without any issue. My employer is mostly a java shop, and I already have to occasionally answer questions from other devs about why this project is in python. My answer has always been that python is a more productive language for this use case, and their retort is that it's not really enterprise ready -- meaning things like stability and support, so that while the language may be faster to initially develop in, the long term maintenance cost will be higher. The lack of respect for backwards compatibility as well as the hostility of the community to basic things like don't break working code is causing me to lose some conviction in my side of this argument. I imagine the same discussion is happening in businesses all over the country. The question is not python 2 or python 3, but python 2 or move away from the language to one that understands my needs. This transition has created a real black eye for python and its role in the commercial space -- at least that's my impression.

iak8god 9y ago
> if we are forced to stop using python 2, we'll probably need to switch the project over to Java. This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. > at least the java community doesn't force developers to rewrite their source code when a new JVM comes out Yes, that was an unfortunate, one-time thing for Python that happened almost a decade ago. > My employer is mostly a java shop ... and their retort is that [python is] not really enterprise ready Yep. That sounds like the kind of nonsense people say in a Java shop.
- coldtea 9y ago
  >This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. Yes, but in return it will bring a 10x performance improvement in lots of areas, and the option of a whole lot more sturdy statically checked code.
  - baq 9y ago
    if performance is a problem, then start rewriting the critical pieces right now because python 2 also isn't for you. mypy is a much better type system than Java, btw, if that's what you're after.
    - iak8god 9y ago
      Can you expand on "mypy is a much better type system than Java"? I'd love it if that were true.
      - baq 9y ago
        It has e.g. a proper Union type, generics and type inference. Lack of pattern matching hurts, but then, Java doesn't have that either. You can also configure how strict you want the checks to be. There are downsides though: type stubs are of... varying... quality, there are ugly hacks needed to resolve cyclic imports and the type annotation syntax gets yucky in places, even in 3.6. I'm using mypy seriously for about a year and it's progressing very well. I see very good ROI even with the uglification of the code.
        iak8god 9y ago
        I'll check it out. Thanks!
      - nayuki 9y ago
        mypy can help you ensure that a variable is never None, whereas it's still tedious to manually check for null in Java.
worldeight 9y ago
As an independent contractor maintaining large Python 2 codebases, your comments really hit home for me. I only have a portion of my time each month to maintain and develop features for them. If the Python 2 floodgate ever breaks, I am more likely to rewrite the system in a statically typed language. Even today, I am tempted. I know that a sibling mentions the ridiculousness of the situation, but a forced depreciation of the Python 2 runtime (see also, Windows) is a billable, justifiable, reason to do the work of refactoring parts of the system. I do not expect those billable hours to happen in the next decade, however.
- rsj_hn 9y ago
  This. I don't think people realize that there are fixed costs that are born in making these kinds of migrations so that migrating to Java from python is not 100x more work than migrating from python 2 to python 3. There is no such thing as a small breaking change to a runtime. Maybe one way of thinking about it is to take a hard drive full of data and randomly flip a few bits. Then ask what the effort is to find and fix all the errors, and whether this effort is a function of the number of bits flipped or the size of the drive. The people who don't understand/have sympathy with my concerns are saying -- it will only introduce a few breaking changes -- but I'm looking at the size of the project. But this condescending attitude coming from some in the python community really isn't helping the language any. I am not saying that everyone has to share my concerns, but they certainly aren't "nonsense" or "ridiculous".
  - brianwawok 9y ago
    If you actually have tests it's not half as bad as you are making it out to be. If your code base is a big pile with no tests.. well you dug that grave.
    - rsj_hn 9y ago
      Sure, we have tests, we have a whole ecosystem -- written in python2 -- but that's not a justification to introduce breaking changes or a guarantee that the tests will catch all regressions. We also have dependencies. Moreover, unless your system is a toy, tests aren't going to give you the same guarantees as having a system be hammered by real world events for 5 years.
catdog 9y ago
> but at least the java community doesn't force developers to rewrite their source code when a new JVM comes out. Java contains a lot of ugly legacy bullshit because of that.
- rsj_hn 9y ago
  Yes. If you're not prepared for cruft, then you are going to be rewriting things all the time. Joel Spolsky talks about this desire for artistic purity over useful backwards compatible cruft in a couple of nice essays: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

by rsj_hn 9y ago

iak8god 9y ago

> if we are forced to stop using python 2, we'll probably need to switch the project over to Java. This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. > at least the java community doesn't force developers to rewrite their source code when a new JVM comes out Yes, that was an unfortunate, one-time thing for Python that happened almost a decade ago. > My employer is mostly a java shop ... and their retort is that [python is] not really enterprise ready Yep. That sounds like the kind of nonsense people say in a Java shop.

coldtea 9y ago
>This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. Yes, but in return it will bring a 10x performance improvement in lots of areas, and the option of a whole lot more sturdy statically checked code.
- baq 9y ago
  if performance is a problem, then start rewriting the critical pieces right now because python 2 also isn't for you. mypy is a much better type system than Java, btw, if that's what you're after.
  - iak8god 9y ago
    Can you expand on "mypy is a much better type system than Java"? I'd love it if that were true.
    - baq 9y ago
      It has e.g. a proper Union type, generics and type inference. Lack of pattern matching hurts, but then, Java doesn't have that either. You can also configure how strict you want the checks to be. There are downsides though: type stubs are of... varying... quality, there are ugly hacks needed to resolve cyclic imports and the type annotation syntax gets yucky in places, even in 3.6. I'm using mypy seriously for about a year and it's progressing very well. I see very good ROI even with the uglification of the code.
      - iak8god 9y ago
        I'll check it out. Thanks!
    - nayuki 9y ago
      mypy can help you ensure that a variable is never None, whereas it's still tedious to manually check for null in Java.

worldeight 9y ago

As an independent contractor maintaining large Python 2 codebases, your comments really hit home for me. I only have a portion of my time each month to maintain and develop features for them. If the Python 2 floodgate ever breaks, I am more likely to rewrite the system in a statically typed language. Even today, I am tempted. I know that a sibling mentions the ridiculousness of the situation, but a forced depreciation of the Python 2 runtime (see also, Windows) is a billable, justifiable, reason to do the work of refactoring parts of the system. I do not expect those billable hours to happen in the next decade, however.

rsj_hn 9y ago
This. I don't think people realize that there are fixed costs that are born in making these kinds of migrations so that migrating to Java from python is not 100x more work than migrating from python 2 to python 3. There is no such thing as a small breaking change to a runtime. Maybe one way of thinking about it is to take a hard drive full of data and randomly flip a few bits. Then ask what the effort is to find and fix all the errors, and whether this effort is a function of the number of bits flipped or the size of the drive. The people who don't understand/have sympathy with my concerns are saying -- it will only introduce a few breaking changes -- but I'm looking at the size of the project. But this condescending attitude coming from some in the python community really isn't helping the language any. I am not saying that everyone has to share my concerns, but they certainly aren't "nonsense" or "ridiculous".
- brianwawok 9y ago
  If you actually have tests it's not half as bad as you are making it out to be. If your code base is a big pile with no tests.. well you dug that grave.
  - rsj_hn 9y ago
    Sure, we have tests, we have a whole ecosystem -- written in python2 -- but that's not a justification to introduce breaking changes or a guarantee that the tests will catch all regressions. We also have dependencies. Moreover, unless your system is a toy, tests aren't going to give you the same guarantees as having a system be hammered by real world events for 5 years.

catdog 9y ago

> but at least the java community doesn't force developers to rewrite their source code when a new JVM comes out. Java contains a lot of ugly legacy bullshit because of that.

rsj_hn 9y ago
Yes. If you're not prepared for cruft, then you are going to be rewriting things all the time. Joel Spolsky talks about this desire for artistic purity over useful backwards compatible cruft in a couple of nice essays: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...