En mi carrera académica, he leído bastantes artículos académicos sobre diversos temas de informática. Muchos de los cuales implican una implementación y alguna evaluación de esa implementación, sin embargo, he descubierto que muy pocos de ellos publican realmente el código que usaron.
Para mí, los beneficios de incluir la implementación real serían significativos, a saber:
- Extensión de confianza o reproducibilidad (¡solo pruébelo usted mismo!)
- Aclaración de ambigüedades (particularmente para trabajos escritos por hablantes no nativos)
- Reutilización de código para aplicaciones
Entonces, ¿por qué tan pocos documentos realmente incluyen algún código?
Supongo que podría ser la intención de la organización detrás del documento utilizar la implementación en sus propias aplicaciones y, por lo tanto, no querría publicarlo, pero si ese es el caso, ¿por qué incluso escribir el documento?
soft-question
research-practice
paper-review
Kevin Dolan
fuente
fuente
Respuestas:
Aquí hay un artículo bien argumentado de David Donoho y Jonathan Buckheit que leí en la escuela de posgrado que aborda exactamente este tema desde el punto de vista de los investigadores de wavelet:
"WaveLab y la investigación reproducible"
Su idea era aún más ambiciosa, proporcionar un código para reproducir todas las figuras en sus documentos en un conveniente paquete de Matlab.
Realmente me gusta su idea, pero creo que los problemas son obvios.
(1) Es un trabajo extra (limpiar el código, hacer al menos una interfaz de usuario rudimentaria, escribir cierta documentación, proporcionar algo de apoyo cuando las personas inevitablemente se encuentran con problemas)
(2) No es realmente requerido / esperado por la mayoría de las conferencias / revisores
Pero no puedo evitar sentir que la comunidad de investigación de CS se beneficiaría si existiera la expectativa de hacer que el código y los datos utilizados en cualquier publicación estén disponibles públicamente en un formato utilizable. Admito que no lo he hecho incluso cuando la cantidad de trabajo involucrado hubiera sido manejable. Creo que es difícil hacer un esfuerzo extra cuando no hay un impulso externo.
fuente
Si trabaja para un laboratorio industrial, puede ser mucho, mucho más fácil obtener un documento aprobado para su publicación que obtener el código aprobado para su publicación (incluso si el documento contiene toda la información necesaria para reescribir el código). Culpa a la burocracia.
fuente
Migrado y expandido de un comentario:
Creo que esto debe variar según el subcampo. Casi todas las cosas de la Teoría B con las que estoy familiarizado (y especialmente Haskell, Agda y, a veces, relacionadas con Coq) incluyen código publicado, a veces incluso como un apéndice o mejor aún, incluido en el documento. Para empezar, un buen número de artículos de, por ejemplo, ICFP están escritos como programas alfabetizados, y los autores publican su fuente en su totalidad. Una buena cantidad de ellos a su vez ha resultado en bibliotecas extraídas para su distribución.
De los documentos restantes, una cantidad justa nunca tuvo código para empezar. De esos, probablemente hay dos razones principales. Primero están los documentos cuyo contenido principal es árboles de pruebas, reglas de mecanografía con pruebas de solidez asociadas y similares. De ellos, los avances en la metateoría mecanizada han alentado al menos a algunos autores a proporcionar código en su probador de teorema de elección (ver las diapositivas de Weirich en POPLmark:) http://www.seas.upenn.edu/~sweirich/talks/cambridge-09. pdf. En segundo lugar están los que descienden de las cosas de Bird-Merteens (banannas & co.). Estos generalmente se pueden traducir a un lenguaje funcional sin demasiado trabajo. Sin embargo, sospecho que generalmente hay una pérdida de generalidad, y que lidiar con problemas concretos de sintaxis y escritura complica innecesariamente las cosas y hace que sea más difícil seguir el razonamiento equitativo.
Quería corroborar un poco mis observaciones, así que hice un recuento aproximado de los primeros dos días de ICFP 2010. De los documentos estándar (es decir, no los informes de experiencia o las conversaciones invitadas), 12 de 21 proporcionaron algún tipo de código. Tres proporcionaron Coq (un cuarto reclamó una prueba parcial pero no la publicó). Tres se burlaron de Haskell. Tres proporcionaron Agda. Uno proporcionó Scheme, uno proporcionó Caml y uno proporcionó Twelf. (Tenga en cuenta que algunos proporcionaron código para más de un asistente de prueba, o tanto para una formalización como para una implementación). Del resto de los documentos, algunos trabajaron con un nivel de abstracción lo suficientemente alto como para que implementarlo en un asistente de prueba sería un documento nuevo en sí mismo, y un buen número más funcionó y sospecho que podría haberse implementado en un asistente de prueba usando técnicas estándar, pero que ciertamente hubieran requerido una gran cantidad de trabajo para hacerlo.
fuente
Usted cree que el código debe publicarse, pero pregunta por qué los documentos no incluyen el código. Estas son dos cosas diferentes.
La mayoría de las veces, simplemente no hay suficiente espacio para publicar una cantidad significativa de código. En mi campo de investigación (procesamiento de imágenes), la información de pseudocódigo o arquitectura a menudo es mucho más valiosa y nunca me he quedado atrapado debido a la falta de código en un documento. A menudo se deja como un ejercicio para el lector que entendió el artículo.
Sin embargo, hay mucho código disponible para ilustrar los documentos. Los autores generalmente tienen una página web e incluso si el revisor no tiene la oportunidad de probar y verificar el código en sí, la selección natural parece funcionar bastante bien y los autores que no publican el código son mucho menos citados.
fuente
Esto ya podría haber sido preguntado hace algún tiempo, sin embargo, siempre me he sentido muy convencido al respecto, así que daré mis dos centavos. He trabajado durante años (ya no) dentro de la comunidad SAT. La mayoría de los investigadores rara vez publican su código. El documento se publica junto con el algoritmo, pero es muy raro ver el código real del solucionador SAT (solucionador MAXSAT), etc., publicado junto con el documento.
Y la realidad es que con solo el código publicado en el artículo, nunca tendrá la oportunidad de reproducir los experimentos del autor. No solo porque el código publicado no está completo (por supuesto) sino también porque incluso el pseudocódigo publicado rara vez se traduce semi-directamente en lo que realmente se implementa.
La razón detrás de esto es difícil de conocer y puede depender de un investigador a otro, pero sobre todo es doble.
Primero, el investigador tiende a trabajar continuamente en un único solucionador publicando documentos después de los documentos sobre el mismo solucionador y agregando gradualmente nuevas características que se traducen en nuevas versiones del solucionador. Existe una obsesión poco saludable de que la competencia utilizará su solucionador para avanzar en sus carreras extendiéndola y publicando documentos sin otorgarle el debido crédito (es decir, coautoría).
En segundo lugar, algunos códigos realmente se escriben (como con todo el software) a toda prisa. Guiones a medio hornear. Características no probadas, etc. Al publicar este código, el investigador sentiría que se avergonzaría y dañaría su reputación.
Os dejo con una referencia reciente sobre esto de ACM: http://cacm.acm.org/magazines/2011/5/107698-the-importance-of-reviewing-the-code/fulltext
fuente
Históricamente, los artículos científicos tenían que imprimirse en papel, y las revistas se enviaban internacionalmente. Cada página adicional solía agregar un costo significativo, por lo que los artículos estaban sujetos a limitaciones de longitud, e incluso el código de trabajo simple generalmente ocupa mucho espacio que una descripción informal.
Hoy no hay una buena razón para no incluir código en ningún tipo de artículo que haga referencia a un algoritmo.
También puede ser útil abandonar los formatos orientados a la impresión como pdf y postscript en favor de formatos más semánticamente conscientes (HTML con MathML o tal vez una variación de código abierto de Mathematica).
fuente