1 Matching Annotations
  1. May 2021
    1. Neither type of language can provide the best documentation by itself; but when both are appropriately combined, we obtain a system that is much more useful than either language separately.

      @ju_anacronica, es lo que mencioné como sinergía porque me acordé de Magic cuando dice esto. El «elemento de la reflexión más que de la documentación» no sé cómo podría nombrarse y por eso lo nombre «publicaciones»; programa, documentación y publicación. Knuth concluye su discurso del premio Turing en 1974 con:

      The present surge of interest in structured programming has revealed that none of our existing languages is really ideal for dealing with program and data structure, nor is it clear what an ideal language should be. Therefore I look forward to many careful experiments in language design during the next few years.

      Para 2008 dice:

      Yet to me, literate programming is certainly the most important thing that came out of the TeX project.

      Otra cosa que también cambia este paradigma es que programa, documentación y publicación es lo que requieren todos los proyectos que hagan uso de recursos computacionales, pero por lo general de producen cada una de manera independiente. El problema de la publicación multiformato desde una sola fuente está resuelto desde hace tiempo, pero sus implementaciones todavían tienen elementos por afinar. Si es formato estandarizado, a mí me parece suficiente. La cuestión del diseño no pienso que tenga que estar en manos de quien produce el formato, sino de quien lo lee o meramente lo consume. Tu das un formato estandarizado, se pueden hacer plugins como «lentes de lectura» que tenga plantillas para poder ver el texto de distintas maneras, he incluso para moverle ciertas cosas. Y que además permita a las personas usuarias generar otras plantillas. Esto fue por lo de Zotero y las plantillas CSL. Hay unas pruebas de un pecas-reader y la idea es probar si se puede hacer un plugin de firefox que esté conectado a un repo de temas (la metáfora aquí es que los temas son plantillas y funcionalidades, diseño y programación sobre texto con estructuración estándar) y pues ver el modo de cómo la banda lo pueda hacer visual y por detrás se guarda el tema. Ahorita el primer tema le estoy poniendo lo que me gusta de un EPUB (lo chido del EPUB para mí es que es tecnología web y las herramientas que me ofrece pa leer; pero su implementación me parece que no ha funcionado, se pueden hacer más sencillos si publicar no es hacer estructura, diseño y un dispositivo especial para funcionalidad, sino publicar estructura y que el usuario le dé diseño o funcionalidad, un HTML como este que hypothesi.is interactúa. Hace unos días hice un tema que le falta tipo de búsqueda y reemplazo, y cambio de familia de fuentes, pero ya genera un índice con los encabezados que tenga el documento, como el de Hedgedoc, más los elementos que ya tenía el menú de publishing is codig).

      Pero aún siendo la publicación una sola fuente, el programa y la documentación siguen siendo en total tres fuentes distintas. La programación literaria la entiendo como un paradigma de hacer también todo esto pero con una sola fuente que sea a su vez programas, documentaciones y publicaciones a partir de una sola fuente. Sin embargo, aún es muy evidente cuál texto es programa o no, se necesitan bloques específicos y por eso es que RWEB funciona, absorbe el pad, escoje solo esos bloques, los pega y ejecuta, y así el programa escrito puede trabajar sobre el mismo texto con el que fue escrito u otros más, en este caso solo modificó la estructura, y lo que quiero ver es modificar el programa y reejecutarlo hasta que cierta cantidad de condiciones estén satisfechas. Un animalario o herbolario, por ejemplo, cada ejecución cambia y genera una ficha, cuantas se quieran porque cada vez se cambian elementos. Si una gramática de 72 palabras para tweets resultaron más de 61,000 tweets, ¿cuántas fichas serán en una gramática que abarque su tamaño? ¿Cuáles cantidades tendrían las gramáticas cuyo tamaño sean un post, un artículo, capítulo, libro, volumen, enciclopedia?

      Lo que voy a hacer es dividir este pad en tres para tres perfiles distintos con los que me relaciono más, los que les podría interesar más el flujo de publicación, los que quisieran ver cómo implementarlo y los que les gustaría leer la investigación. Además voy a poner en otro pad lo de la gramática de libre contexto, porque aquí ni siquiera se aplica, entonces en el otro trabajaré de cómo hacerlo ejecutable. Dejarlo pegado me parece que ya excede el tamaño de un post, entonces serán post distintos. Ojalá que también así sea más ameno para la lectura.