5 ms·

What about code people wrote before 2010 that were perfectly fine? Are you going to have people rewrite research algorithms whose original authors have long gra

What about code people wrote before 2010 that were perfectly fine? Are you going to have people rewrite research algorithms whose original authors have long graduated? Just because industry has a habit of rewriting the whole stack every five years on account of make-work job security doesn't make foundational scientific algorithms change.

philderbeast 6y ago
if the code still has value being run in modern environments, then it probably needs to be maintained and updated anyway. if its not being used, then does it running with the latest tools even matter?
- lanstin 6y ago
  Not really. For example R ships with or depends on a lot of FORTRAN libraries. I doubt they have changed much at all in decades. There is no talk of a breaking FORTRAN language change that would require rewriting this perfectly FB ctional code with a stable interface.
michaelmrose 6y ago
Couldn't you isolate the entire outdated environment this 2002-2009 code is expected to run in? Plenty of code written in this time frame is liable to depend on unsupported things by that point.
bastawhiz 6y ago
Except the Python folks produced tools that did almost all of the work for you. 2to3 has worked for an overwhelming number of use cases. And in fact, most code requires very few changes to begin with. If this academic code isn't well understood or well tested, it's probably not as valuable as you might think.
- dwheeler 6y ago
  > 2to3 has worked for an overwhelming number of use cases. And in fact, most code requires very few changes to begin with. That is not at all my experience, nor is that experience of most other people I've ever talked to.
  - __turbobrew__ 6y ago
    I ran 2to3 on 1 of about 200 modules at my workplace codebase and it took me about an hour to run 2to3 and fix up the leftovers in that module. Now do that for 199 other modules and it becomes much more work than “just run 2to3”.
  - joshuamorton 6y ago
    In the migration I was a part of (probably one of the larger ones, period), I think something like 90% of code could be migrated by automation. And of the remaining 10, most of it needed only trivial human oversight. That remaining two percent had a lot of painful things (truly, I have some stories), but "the overwhelming number of use cases" was trivial.
  - bastawhiz 6y ago
    I migrated a large codebase with 2to3 and six. It took me half a day. 2to3 did roughly 60-75% of the work and six cleaned up almost all of the rest. It's not foolproof, but it is surely better than nothing. It's perhaps also worth noting that I did this in late 2017. Your experience likely varies depending on when you attempted it.
- rleigh 6y ago
  2to3 does 95% of the job. The other 5% requires manually fixing up all the bits it missed, and until you do that, your codebase will be subtly (not not so subtly) broken. The most common problem I saw was relating to iterating over dictionary keys. That 5% that requires manually fixing up is the sticking point. You still need to audit every line of the codebase, and each line that gets missed is a guaranteed bug introduced to your codebase by the conversion. This is not much of an issue for small scripts or tiny programs. It is an issue for big applications. This migration really highlights (yet again), the dangers of using interpreted languages at scale. With no compiler to pick up errors, no typechecking by default etc., identifying all of the remaining faults is a huge task. Like it or not, this is a huge risk to a business. There is a risk of introducing vast quantities of bugs, and there a huge developer cost to performing the migration. For the record, I have migrated several medium-sized codebases with 2to3 and python-modernize. Because these were internal tools with defined inputs and outputs, it was trivial to validate that the behaviour was unchanged after the conversion. But for most projects this will not be the case. The 2 to 3 conversion will be a textbook case of what not to do for many decades to come. For the many billions it will cost for worldwide migration efforts, the interpreter could have retained two string types and handled interpreting both old and new scripts. The cost would have been several orders of magnitude less.

philderbeast 6y ago

if the code still has value being run in modern environments, then it probably needs to be maintained and updated anyway. if its not being used, then does it running with the latest tools even matter?

lanstin 6y ago
Not really. For example R ships with or depends on a lot of FORTRAN libraries. I doubt they have changed much at all in decades. There is no talk of a breaking FORTRAN language change that would require rewriting this perfectly FB ctional code with a stable interface.

michaelmrose 6y ago

Couldn't you isolate the entire outdated environment this 2002-2009 code is expected to run in? Plenty of code written in this time frame is liable to depend on unsupported things by that point.

bastawhiz 6y ago

Except the Python folks produced tools that did almost all of the work for you. 2to3 has worked for an overwhelming number of use cases. And in fact, most code requires very few changes to begin with. If this academic code isn't well understood or well tested, it's probably not as valuable as you might think.

dwheeler 6y ago
> 2to3 has worked for an overwhelming number of use cases. And in fact, most code requires very few changes to begin with. That is not at all my experience, nor is that experience of most other people I've ever talked to.
- __turbobrew__ 6y ago
  I ran 2to3 on 1 of about 200 modules at my workplace codebase and it took me about an hour to run 2to3 and fix up the leftovers in that module. Now do that for 199 other modules and it becomes much more work than “just run 2to3”.
- joshuamorton 6y ago
  In the migration I was a part of (probably one of the larger ones, period), I think something like 90% of code could be migrated by automation. And of the remaining 10, most of it needed only trivial human oversight. That remaining two percent had a lot of painful things (truly, I have some stories), but "the overwhelming number of use cases" was trivial.
- bastawhiz 6y ago
  I migrated a large codebase with 2to3 and six. It took me half a day. 2to3 did roughly 60-75% of the work and six cleaned up almost all of the rest. It's not foolproof, but it is surely better than nothing. It's perhaps also worth noting that I did this in late 2017. Your experience likely varies depending on when you attempted it.
rleigh 6y ago
2to3 does 95% of the job. The other 5% requires manually fixing up all the bits it missed, and until you do that, your codebase will be subtly (not not so subtly) broken. The most common problem I saw was relating to iterating over dictionary keys. That 5% that requires manually fixing up is the sticking point. You still need to audit every line of the codebase, and each line that gets missed is a guaranteed bug introduced to your codebase by the conversion. This is not much of an issue for small scripts or tiny programs. It is an issue for big applications. This migration really highlights (yet again), the dangers of using interpreted languages at scale. With no compiler to pick up errors, no typechecking by default etc., identifying all of the remaining faults is a huge task. Like it or not, this is a huge risk to a business. There is a risk of introducing vast quantities of bugs, and there a huge developer cost to performing the migration. For the record, I have migrated several medium-sized codebases with 2to3 and python-modernize. Because these were internal tools with defined inputs and outputs, it was trivial to validate that the behaviour was unchanged after the conversion. But for most projects this will not be the case. The 2 to 3 conversion will be a textbook case of what not to do for many decades to come. For the many billions it will cost for worldwide migration efforts, the interpreter could have retained two string types and handled interpreting both old and new scripts. The cost would have been several orders of magnitude less.