4 ms·

> It is, however, a huge problem for domains like scientific computing, where most code has no maintainers and even for very important code there is no budget o

by flukus 7y ago

> It is, however, a huge problem for domains like scientific computing, where most code has no maintainers and even for very important code there is no budget or staff for maintenance I think that's a tool selection problem, not just confined to the python world. If the language and libraries won't have a supported lifespan that matches with the maintenance budget of the projects using them then the wrong tool was chosen. If a project is expected to have a 10+ year lifespan of little to no maintenance then it needs to be built on languages/libraries that will have supported versions for that long.

jnxx 7y ago
Well, first thing is that most new code in scientific research is developed in PhD projects which last some three or maybe four years. The people who develop this do not have resources and time to maintain this code. Projects don't have a budget for that. There are projects which are very long-running (think CERN or ESO's VLT) but even there the true duration of the code usage is seldomly planned (AFAIK, ESO VLT has just started to transition from Tk/Tcl to Python). You could say then, "well, then Python is perhaps just not a good match for those pesky scientists". And this brings up two more points: * A lot of important tools and libraries in the Python ecosystem was developed by scientists. Numarray/Numpy is a good example. * If the core Python developers don't have the intention to maintain a backwards-compatible language version for more than, say, 15 years, they should perhaps clearly state on the python.org main page something like: "great, as you are a scientist, we welcome your contribution, but Python might not be suitable for tools that support long-term research".
- cmacleod4 7y ago
  "ESO VLT has just started to transition from Tk/Tcl to Python" - they might regret this, new Tcl releases tend to take backward compatibility much more seriously than Python :-)
  - blacksqr 7y ago
    Yes, I've always thought that Tcl should be promoted as an archival quality programming language.

by flukus 7y ago

jnxx 7y ago

Well, first thing is that most new code in scientific research is developed in PhD projects which last some three or maybe four years. The people who develop this do not have resources and time to maintain this code. Projects don't have a budget for that. There are projects which are very long-running (think CERN or ESO's VLT) but even there the true duration of the code usage is seldomly planned (AFAIK, ESO VLT has just started to transition from Tk/Tcl to Python). You could say then, "well, then Python is perhaps just not a good match for those pesky scientists". And this brings up two more points: * A lot of important tools and libraries in the Python ecosystem was developed by scientists. Numarray/Numpy is a good example. * If the core Python developers don't have the intention to maintain a backwards-compatible language version for more than, say, 15 years, they should perhaps clearly state on the python.org main page something like: "great, as you are a scientist, we welcome your contribution, but Python might not be suitable for tools that support long-term research".

cmacleod4 7y ago
"ESO VLT has just started to transition from Tk/Tcl to Python" - they might regret this, new Tcl releases tend to take backward compatibility much more seriously than Python :-)
- blacksqr 7y ago
  Yes, I've always thought that Tcl should be promoted as an archival quality programming language.