methodology - lenguaje de programación tex

¿Programación de escalamiento alfabetizado? (8)

Saludos. He estado mirando un poco la Programación Literaria, y me gusta la idea que hay detrás: básicamente escribes un pequeño artículo sobre tu código y anotas la mayor parte de las decisiones de diseño, el código que probablemente rodea el módulo, el trabajo interno de el módulo, las suposiciones y las conclusiones resultantes de las decisiones de diseño, extensión potencial, todo esto se puede escribir de una manera agradable usando tex. De acuerdo, el primer punto: es documentación. Debe mantenerse actualizado, pero eso no debería ser tan malo, porque su cambio debe tener una justificación y puede escribirlo.

Sin embargo, ¿cómo se escala la programación de alfabetización en mayor grado? En general, la Programación Literate sigue siendo solo texto. Texto legible muy humano, por supuesto, pero sigue siendo texto, y por lo tanto, es difícil seguir sistemas grandes. Por ejemplo, volví a trabajar grandes partes de mi compilador para usar >> y algo de magia para encadenar los pasos de compilación juntos, porque algunos "x.register_follower (y); y.register_follower (z); y.register_follower (a); ... "se volvió muy difícil de manejar, y cambiar eso a x >> y >> z >> a lo hizo un poco mejor, aunque también está en su punto de ruptura.

Entonces, ¿cómo escala Literate Programming en sistemas más grandes? ¿Alguien intenta hacer eso?

Mi idea sería usar LP para especificar componentes que se comuniquen entre sí usando flujos de eventos y encadenarlos todos juntos usando un subconjunto de graphviz. Esta sería una extensión bastante natural de LP, ya que puede extraer una documentación (un diagrama de flujo de datos) de la red y también generar código de ella realmente bien. ¿Que piensas de eso?

- Tetha.

El libro "Representación Física Basada" (pbrt.org) es el mejor ejemplo de programación literaria a gran escala del que soy consciente. El libro implementa un sistema de representación completo, y tanto el texto del libro como el código raytracer se generan a partir de la misma "fuente".

En la práctica, descubrí que solo usar un sistema como Doxygen y realmente profundizar y utilizar todas sus características es mejor que la programación "alfabetizada" en toda regla, a excepción de cosas como esta, es decir, libros de texto, materiales educativos.

Excelente pregunta La motivación para la programación alfabetizada nunca desaparecerá, pero creo que debería tratarse como algo fluido. Significa "dar un descanso al lector y educarlos sobre lo que estás tratando de hacer". No creo que signifique "hacer que tu código sea realmente prolijo".

Dicho esto, el lector tendrá que esforzarse un poco, dependiendo de lo que ya sabe. Es de suponer que el código vale la pena entenderlo, y nada es gratis.

También creo que significa más que solo hacer código legible. Lo más probable es que la razón por la que alguien está leyendo el código es porque necesitan hacer un cambio. Debe anticipar los posibles cambios que podrían ser necesarios y decirles cómo hacerlo si es necesario.

La Programación alfabetizada se desarrolló en una época en la que los nombres largos de variables y funciones simplemente no eran posibles. Debido a esto, el código realmente no era tan legible.

Obviamente, han sucedido muchas cosas desde entonces.

En el mundo de hoy, el código en sí es la documentación, de ahí el término "código de auto documentación". La realización es que ningún conjunto de comentarios o documentación externa puede permanecer sincronizado con el código subyacente. Entonces, la meta de muchos programadores de hoy es escribir el código de tal manera que sea legible para otros.

pbrt es un rastreador de rayo basado en la física escrito en el estilo alfabetizado para la educación de graduados en informática (y yo), es un sistema de escala moderadamente grande. Como programador no especializado, este nivel de documentación es bastante esencial para comprender lo que hace el programa y por qué lo hace.

También tengo acceso a un procesador de investigación, en Java, que está bien escrito pero relativamente indocumentado, pero para unos pocos documentos SIGGRAPH. Esto también es relativamente comprensible, pero también tengo acceso a los autores.

También utilicé ImageJ bastante y miré bajo el capó subyacente de Java, es bastante difícil de seguir sin una idea de la filosofía subyacente.

En resumen, mi punto de vista es que la programación alfabetizada es excelente si alguien puede encontrar el tiempo para hacerlo bien y es probable que sea en entornos educativos. Es difícil verlo hecho en la producción de código comercial. Soy escéptico de la idea de que el código puede ser totalmente autodocumentado.

Hice algo de programación literaria con WEB hace unos 15 años. Más recientemente intenté extraer código de una wiki y generar documentación de un entorno Squeak Smalltalk.

La parte ascendente se puede manejar relativamente bien generando documentos a partir de marcos TDD / BDD, pero LP se centra en explicar el código al lector.

Hay algunos problemas:

la historia que contar es diferente para diferentes partes interesadas / lectores;
la estructura del proyecto en la mayoría de los entornos no es la estructura necesaria para contar historias;
no se admite el refinamiento / revelación sucesiva;
además del soporte de texto para las imágenes es necesario;
de los comentarios en el sistema de control de fuente uno puede derivar cómo el sistema fue construido. La historia debería ser cómo el sistema podría haber sido construido (con una perfecta visión retrospectiva).

Para que LP funcione para sistemas más grandes, necesita una mejor compatibilidad IDE que una wiki o un buscador de objetos.

La idea detrás de la programación alfabetizada es el énfasis en la documentación, con el código salpicado a través de la documentación, en lugar de comentarios salpicados a través del código.

Esta es una filosofía esencialmente diferente, y las diferencias como nombres de variables más largos, espacios de nombres y clases no afectan la filosofía. La programación alfabetizada aboga por nombres de variables significativos.

Se adapta a sistemas más grandes, porque la relación básica de la documentación al código se amplía linealmente con el tamaño del código.

"En general, la programación de lectura y escritura sigue siendo solo texto"

Falso.

Los diagramas están bien.

Mi idea sería usar LP para especificar componentes que se comuniquen entre sí usando secuencias de eventos

Eso es solo arquitectura, y eso está bien.

puede extraer una documentación (un diagrama de flujo de datos) de la red y también generar código muy bien. ¿Que piensas de eso?

Los diagramas de flujo de datos no son realmente tan útiles para generar código detallado. Son un resumen útil, no una fuente precisa de información.

Una buena herramienta de escritura (como LaTex) puede codificar el diagrama en el documento. Probablemente pueda encontrar una forma de llegar al diagrama desde otras partes de la documentación.

Línea de fondo

A la larga, es mejor que generes el diagrama como un resumen del texto.

¿Por qué?

Los diagramas intencionalmente elide los detalles. Un diagrama es un resumen o una descripción general. Pero como fuente de código, los diagramas son terribles. Para proporcionar todos los detalles, los diagramas se vuelven muy desordenados.

Pero un resumen diagramático de algunas otras marcas LP funcionará bien.

Pruebe la herramienta extensible NanoLP - LP, admite muchos formatos de documentos (Markdown, OpenOffice, Creole, TeX, Asciidoc y otros), la importación de otros programas LP, plantillas y más. El usuario puede agregar sus propios comandos / macros (en Python), por ejemplo para realizar importaciones especiales, por ejemplo, desde VCS ... http://code.google.com/p/nano-lp