Mantenimiento de software en investigación
Edición para Python Edición para JVM Blog … biblioteca —> Mantenimiento de software en la investigación por Konrad Hinsen, publicado el 26 de febrero de 2014 El mantenimiento de software es una de las dificultades a las que se enfrentan habitualmente los desarrolladores de software científico. Es una actividad importante, pero puede consumir mucho tiempo y apenas recibe reconocimiento en los procedimientos de evaluación actuales.
Además, si gestionas un proyecto de software de gran envergadura, suele ser difícil conseguir financiación para su mantenimiento. Dado que el mantenimiento de software es complicado y no tiene un interés científico intrínseco, deberíamos preguntarnos por qué es necesario y si podemos hacer algo para reducir esa necesidad. En primer lugar, ¿qué es el mantenimiento de software? Merriam-Webster define el verbo “maintain” (mantener) como conservar (algo) en buen estado mediante reparaciones, corrección de problemas, etc.
Esto tiene sentido para equipos técnicos que se deterioran con el tiempo debido al desgaste mecánico, entre otros factores. El software no se deteriora, por lo que el mantenimiento debe significar algo diferente cuando se aplica al software. No conozco ninguna definición consensuada, así que la que presento aquí es la mía: El mantenimiento de software consiste en modificar el software por una de estas dos razones: Corregir errores.
Mantener el software utilizable en entornos informáticos en evolución. Algunas personas añadirían a esta lista mejoras funcionales, pero estas no son realmente mantenimiento en ningún sentido, sino mejoras. Esto es especialmente cierto en el caso del software científico, donde nueva funcionalidad a menudo significa nueva ciencia.
Primero, los errores. Al igual que con cualquier software, queremos que los errores del software científico se corrijan para obtener mejores resultados en el futuro.
Sin embargo, también queremos conservar la versión con errores si algún estudio científico publicado la ha utilizado. Se trata simplemente de una cuestión de honestidad y preservación del registro científico: si existe la posibilidad de que el resultado de un estudio se haya visto influenciado por un error en el software, las personas que examinen dicho estudio deberían poder descubrirlo. Deben tener acceso exactamente al mismo software que se utilizó originalmente, no solo a su sucesor mejorado actual.
Relacionado: — Cursos interactivos de Python y ciencia de datos que codifica directamente en el navegador.
Por esta razón, es en realidad más importante preservar el código que se utilizó en un estudio que corregir los errores. ActivePapers fue diseñado con este objetivo en mente: cualquier elemento de datos calculado en un ActivePaper está vinculado al software que lo produjo.
Además, este vínculo es estrictamente inmodificable tras la publicación, ya que los ActivePapers se publican al igual que las copias electrónicas de artículos y se referencian mediante DOIs. Puedes hacer trampas antes de la publicación modificando un ActivePaper con la intención específica de cometer fraude. ActivePapers no admite tales acciones, pero tampoco realiza ningún esfuerzo por prevenir el fraude. Estas funcionalidades podrían añadirse protegiendo la información de procedencia con hashes, pero espero que esto no sea necesario.
El segundo problema, la evolución de los entornos informáticos, es más sutil. Es un hecho innegable que todo en el mundo de la informática (ordenadores, sistemas operativos, compiladores, definiciones de lenguajes, bibliotecas, etc.) cambia a gran velocidad, con el resultado de que es poco probable que un fragmento de código fuente determinado funcione tal cual unos años después. Esto ocurre por dos razones: (1) el progreso técnico permite ordenadores y software cada vez mejores, que es lo que la gente desea, y (2) nadie tiene un interés creado en la estabilidad de las plataformas informáticas ni el poder para lograrla.
Favorito del lector: — Rutas de ciencia de datos basadas en proyectos con una terminal guiada y conjuntos de datos reales.
Para los fabricantes de hardware y los proveedores de software comercial, el cambio rápido es la mejor manera de asegurar que los clientes compren nuevas máquinas y actualicen sus licencias regularmente. Por supuesto, hay al menos una comunidad que sí tiene un interés creado en la estabilidad de las plataformas informáticas: la comunidad de la ciencia computacional. Si pudiéramos ejecutar nuestro software 20 años después, sin modificaciones, y obtener los mismos resultados, estaríamos encantados.
No queremos realizar mantenimiento de software, y la mayoría de nosotros no podemos mantener razonablemente el software que desarrollamos para nuestra propia investigación más allá de nuestras necesidades personales inmediatas. Es aún menos razonable esperar que alguien mantenga el software de otra persona, por ejemplo, el software dejado por un estudiante de doctorado que ahora trabaja en la industria.
En la práctica, solo el software comunitario ampliamente utilizado se mantiene durante períodos suficientemente largos. Pero incluso los proyectos de investigación que utilizan paquetes ampliamente usados y mantenidos suelen requerir también cierto software específico del proyecto, como mínimo un par de scripts de shell. Y esa es una de las razones por las que la reproducibilidad de los estudios computacionales es tan deficiente. ¿Podría la comunidad científica hacer algo al respecto? Creo que sí, pero no soy optimista respecto a que tome medidas en un futuro próximo.
Es probable que los científicos continúen utilizando hardware convencional para la computación científica, lo que significa que tendrán que aceptar la evolución del hardware y del software de sistema asociado, que escapa a su control. Sin embargo, pueden construir una plataforma estable sobre estas bases en constante evolución, al menos para la parte puramente computacional de su trabajo.
A nivel fundamental, todas las notaciones de software Turing-completas son equivalentes y pueden convertirse entre sí. En la práctica, las consideraciones de rendimiento imponen un límite a la conversión de código, pero sigue siendo posible definir representaciones de código que puedan traducirse eficientemente a todo tipo de hardware subyacente y software de sistema, permaneciendo así estables. Dos ejemplos reales son el bytecode de la JVM y la forma intermedia de LLVM. El bytecode de la JVM lleva existiendo 20 años y ha demostrado ser extremadamente estable.
La forma intermedia de LLVM no está diseñada para ser estable, pero eso se debe a que los desarrolladores de LLVM no quieren limitar sus opciones futuras comprometiéndose con una representación estable. El proyecto PNaCl de Google intenta ignorar esta advertencia y utilizar el código LLVM de una manera que solo tenga sentido si permanece estable. El tiempo dirá cómo funciona esto.
La comunidad científica podría definir su propia representación de código intermedio, basándose en la experiencia con enfoques existentes y optimizando su plataforma para aplicaciones científicas. Pero, como he dicho antes, no soy optimista sobre que esto ocurra. Dos requisitos serían un compromiso a largo plazo por parte de varias grandes organizaciones de investigación y financiación para mantener esta plataforma durante muchas décadas.
Estoy convencido de que esto sería económicamente razonable, porque estoy seguro de que mantener una plataforma es más barato que mantener numerosos paquetes de software científico y reescribir constantemente aquellos que no se mantienen. Pero requeriría un nivel de acuerdo y compromiso que es raro en la ciencia; solo ha ocurrido para unas pocas instalaciones enormes como CERN.
La importante ventaja que proporciona una plataforma estable es la razón por la que la primera edición de ActivePapers se diseñó en torno a la JVM. Desafortunadamente, la JVM no es muy popular en la computación científica. A menudo se explica por una falta de rendimiento, aunque ese argumento ya no es tan válido como solía serlo. También hay algunos problemas de diseño, en particular concerning operaciones de punto flotante, pero lo mismo puede decirse de lenguajes populares como C o C++, lo cual no ha impedido que los científicos los utilicen.
La edición de ActivePapers para Python, prácticamente más útil, se basa en una plataforma definida por el ecosistema de Scientific Python (en particular Python, NumPy y h5py). Esta plataforma ha demostrado ser moderadamente estable en el pasado, siendo la transición a Python 3 el principal evento de inestabilidad.
La escala temporal sobre la cual la científica
Lectura complementaria
- SciPy — Wikipedia
Sea propietario de un curso de por vida, no de una suscripción
Compre cursos individuales de Python científico directamente, frecuentemente con grandes descuentos