La edición Pharo de ActivePapers
Edición para Python Edición para JVM Edición para Pharo Blog … biblioteca —> La edición de ActivePapers para Pharo, por Konrad Hinsen, publicado el 10 de mayo de 2019 La familia ActivePapers tiene un nuevo miembro: la edición de ActivePaper para Pharo. A diferencia de las ediciones para Python y JVM, que implementan básicamente las mismas ideas y conceptos en dos plataformas distintas, la edición para Pharo persigue un objetivo diferente: explorar la interfaz humano-computadora para una investigación asistida por ordenador que sea reproducible, comprensible y verificable.
Una de las preguntas más frecuentes que recibí sobre la edición de ActivePapers para Python fue: “¿Funciona esto con los notebooks de Jupyter?” Inicialmente, mi respuesta fue: “Todavía no, pero estoy trabajando en ello”. Y así lo hice. Sin embargo, ese trabajo nunca condujo a un resultado satisfactorio. Una de las razones fueron los obstáculos técnicos.
Intenté incluir notebooks de Jupyter dentro de un ActivePaper, pero resultó imposible porque el diseño de dos procesos de Jupyter (el kernel y el editor del notebook son procesos separados conectados mediante un protocolo de comunicación) no era compatible con la restricción de la biblioteca HDF5, que solo permite que un proceso escriba en un archivo en un momento dado. Esto significa que no se puede almacenar un notebook y los resultados que calcula en el mismo archivo HDF5. Sin embargo, cuanto más reflexionaba sobre la integración de ActivePapers y Jupyter, más me daba cuenta de que sus notebooks lineales (una secuencia de celdas de código, documentación y resultados) no están realmente adaptados a la tarea de documentar un cálculo científico, excepto en casos simples.
Si observamos los diversos ActivePapers publicados, invariablemente contienen múltiples scripts además de algunos módulos de biblioteca. Superficialmente, podría parecer que los notebooks pueden reemplazar los scripts y proporcionar así documentación. No obstante, una buena documentación debe documentar el conjunto, no solo algunas de sus partes.
Debe entrelazar múltiples scripts y código procedente de los módulos de biblioteca. Por lo general, los métodos computacionales se implementan en los módulos de biblioteca, y los scripts los aplican a conjuntos de datos.
Si la documentación se realiza script por script, ¿cómo se documentan los métodos? Hoy en día hay abundantes notebooks de Jupyter publicados; ¿cómo abordan esto? Por supuesto, no los examiné todos, pero hasta ahora mi impresión es que hay dos casos. El caso más frecuente son notebooks que documentan análisis de datos basados en métodos estándar bien conocidos, implementados en bibliotecas igualmente conocidas.
Relacionado: — Cursos interactivos de Python y ciencia de datos que codifica directamente en el navegador.
Se espera que los lectores del notebook estén familiarizados con los métodos o que aprendan sobre ellos en otro lugar. El otro caso son notebooks que incluyen la implementación completa del método.
Además de estar limitados a métodos simples, este enfoque tiene la gran desventaja de que la implementación del método no es reutilizable. Dado que mi propia investigación se centra principalmente en desarrollar y evaluar nuevos métodos computacionales, llegué a la conclusión de que los notebooks no son adecuados para mi trabajo. De hecho, ya había llegado a esa misma conclusión mediante la práctica. Cada vez que iniciaba un nuevo proyecto como un notebook, rápidamente cambiaba a módulos y scripts al estilo tradicional, con la documentación en archivos de texto separados.
Descubrí que esta era una técnica perfectamente adecuada para mi uso personal, pero un conjunto de archivos, aunque estén bien organizados, no constituye algo que otro científico, incluso un colaborador, esté ansioso por explorar en profundidad. Cuando comencé a examinar Pharo hace unos meses, en gran parte por casualidad (me inscribí en el MOOC de Pharo para obtener experiencia desde la perspectiva del estudiante, antes de asumir el rol de instructor en el MOOC de Investigación Reproducible), descubrí un tipo muy diferente de entorno informático interactivo.
Vale la pena echarle un vistazo: — Una suscripción para certificados de ciencia de datos y Python respaldados por la universidad.
La familia Smalltalk, de la cual Pharo es uno de los miembros más jóvenes, tiene una larga historia de valoración de la explorabilidad y la comprensibilidad (consulte esta entrada del blog para más detalles). Luego descubrí rápidamente el Glamorous Toolkit, un nuevo entorno interactivo construido sobre Pharo que aspira a un nivel aún mayor de explorabilidad mediante herramientas de desarrollo moldeables; la idea es que los desarrolladores puedan extender el entorno con herramientas de inspección específicas para cada dominio.
Los fundamentos intelectuales de estas ideas han sido resumidos acertadamente en una entrada del blog de Rafael Luque. En comparación con los entornos actuales y futuros del universo Pharo, los notebooks computacionales se sienten muy limitados y restrictivos.
Lo cual no es realmente sorprendente considerando sus orígenes. Los Jupyter y RMarkdown actuales son variaciones menores de la idea de notebook introducida a principios de la década de 1980 por Mathematica. Mathematica, a su vez, como la mayoría de los demás sistemas de álgebra computacional, se basó en el legado de Lisp, que en la década de 1950 introdujo muchas características revolucionarias en la informática, entre ellas la interactividad mediante el bucle Leer-Evaluar-Imprimir (REPL), que era una forma natural de implementar la interacción dentro de las limitaciones del hardware de interfaz de usuario de la época: un terminal orientado a líneas.
Smalltalk, por otro lado, surgió en la década de 1970 con pantallas gráficas y dispositivos apuntadores desde el principio, al precio de depender de hardware al que muy pocas personas tenían acceso en aquel entonces. Como nos enseñó Marshall McLuhan, primero damos forma a nuestras herramientas y luego nuestras herramientas nos dan forma a nosotros.
Los terminales orientados a líneas de la década de 1950 imprimieron una forma de pensar en los usuarios de computadoras que incluso los notebooks computacionales actuales han retenido, a pesar de que existen enfoques superiores desde hace décadas. Y esa tecnología superior no es únicamente Smalltalk, que siempre ha permanecido como un sistema de nicho. Las interfaces gráficas de usuario (GUI) no lineales son lo que todos utilizamos para trabajar con imágenes o archivos de sonido. Esas tareas son casi imposibles de realizar línea por línea, por lo que realmente no existían antes de las GUI.
Para los cálculos, las GUI probablemente llegaron demasiado tarde: el pensamiento lineal ya se había convertido en una norma cultural. La edición de ActivePapers para Pharo tiene como objetivo moldear el entorno GToolkit para convertirlo en un entorno dedicado a la investigación asistida por computación, en lugar del desarrollo de software. Estas dos actividades son distintas pero comparten muchas características comunes.
La principal diferencia es que la ciencia se centra en los datos y en los modelos, siendo el software solo un medio para un fin. Sin embargo, es un medio tan importante que todo lo demás se estructura en torno a él. Además, el desarrollo de software también trata con datos (sobre software) y modelos (como especificaciones).
Al final, las diferencias son graduales más que fundamentales. Este viaje apenas acaba de comenzar, y realmente no sé a dónde llevará. ¡Estén atentos a las actualizaciones!
Mientras tanto, pueden ver este video de demostración. comentarios impulsados por Disqus
Cree un portafolio de datos, proyecto por proyecto
Rutas de ciencia de datos basadas en proyectos con una terminal guiada y conjuntos de datos reales