Pregunta

Saludos. He estado estudiando un poco la programación literaria ahora, y me gusta la idea detrás de esto: básicamente escribes un pequeño documento 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, los supuestos y las conclusiones resultantes de las decisiones de diseño, la extensión potencial, todo esto se puede escribir de una manera agradable usando tex. De acuerdo, el primer punto: es la 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 escala Literate Programming en mayor medida? En general, la programación literaria sigue siendo solo texto. Texto legible muy humano, por supuesto, pero aún texto, y por lo tanto, es difícil seguir sistemas grandes. Por ejemplo, modifiqué grandes partes de mi compilador para usar > > y algo de magia para encadenar los pasos de compilación, 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, a pesar de que también está en su punto de ruptura.

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

Mi idea sería utilizar LP para especificar componentes que se comunican entre sí mediante secuencias de eventos y encadenar todo esto mediante un subconjunto de graphviz. Esta sería una extensión bastante natural para LP, ya que puede extraer una documentación, un diagrama de flujo de datos, de la red y también generar código a partir de ella realmente bien. ¿Que piensas de eso?

- Tetha.

¿Fue útil?

Solución

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

Dicho esto, el lector tendrá que esforzarse un poco, dependiendo de lo que ya sepa. Presumiblemente vale la pena entender el código, y nada viene 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 necesita hacer un cambio. Debe anticipar los posibles cambios que puedan ser necesarios y decirles cómo hacerlo si es necesario.

Otros consejos

El libro '' Representación basada en la física '' (pbrt.org) es el mejor ejemplo de programación alfabetizada a gran escala que conozco. El libro implementa un sistema de renderizado completo, y tanto el texto del libro como el código del trazador de rayos se generan a partir de la misma fuente.

En la práctica, descubrí que usar un sistema como Doxygen y realmente investigar y utilizar todas sus características es mejor que el alfabetizado completo. programación, a excepción de cosas como esta, es decir, libros de texto, materiales educativos.

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

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

Hay algunos problemas:

  • la historia para 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;
  • falta soporte para el refinamiento / divulgación sucesivos;
  • además del soporte de texto para imágenes es necesario;
  • de los comentarios en el sistema de control de origen se puede derivar cómo se construyó el sistema. La historia debería ser cómo se pudo construir el sistema (en retrospectiva perfecta).

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

  

" En general, la programación literaria es   sigue siendo solo texto "

Falso.

Los diagramas están bien.

  

Mi idea sería utilizar LP para especificar componentes que se comunican entre sí mediante secuencias de eventos

Eso es solo arquitectura, y está bien.

  

puede extraer una documentación, un diagrama de flujo de datos, de la red y también generar código a partir de ella realmente bien. ¿Qué opinas 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 podría encontrar una forma de diagrama desde otras partes de la documentación.

Conclusión

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

¿Por qué?

Los diagramas eluyen detalles intencionalmente. 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 esquemático de algún otro marcado LP funcionará bien.

pbrt es un trazador de rayos con base física escrito en estilo literario 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 algunos documentos SIGGRAPH. Esto también es relativamente comprensible, pero también tengo acceso a los autores.

También he usado ImageJ bastante, y busqué debajo el capó en Java subyacente: es bastante difícil de seguir sin una idea de la filosofía subyacente.

En resumen, mi opinión 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 ver que se haga en la producción de códigos comerciales. Soy escéptico ante la idea de que el código pueda ser completamente autodocumentado.

La idea detrás de la programación alfabetizada es el énfasis en la documentación, con código espolvoreado a través de la documentación, en lugar de comentarios espolvoreados 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 literaria aboga por nombres de variables significativos.

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

La programación literaria se desarrolló en una era 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, mucho ha sucedido desde entonces.

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

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top