Programación de escalamiento alfabetizado?

Question

Saludos. He estado buscando en la Programación Literaria un poco ahora, y me gusta la idea detrás de esto: 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 del módulo, suposiciones y 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 funciona la escala de alfabetización de programació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ó realmente 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 se escala la Programación Literate a sistemas más grandes? ¿Alguien intenta hacer eso?

Mi idea sería usar LP para especificar componentes que se comuniquen entre sí mediante el uso de secuencias de eventos y encadenar todas estas juntas utilizando 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.

Answer 1

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 simplemente 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.

Answer 2

Literate Programming 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 pasado 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.

Answer 3

El libro "Representación física en base" (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, he encontrado que solo usar un sistema como Doxygen y realmente profundizar y hacer uso de todas sus características es mejor que la programación completa "alfabetizada", excepto por cosas como esta, es decir, libros de texto, materiales educativos.

Answer 4

pbrt es un rastreador de rayo con base física escrito en el estilo alfabetizado para la educación de los 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 investigador, 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 utilicé ImageJ bastante, y miré debajo del capó en el subyacente 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 esto ocurra 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.

Answer 5

Hice algunos programas de alfabetización 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 de abajo hacia arriba se puede manejar relativamente bien generando documentos de marcos TDD/BDD, pero LP se centra en explicar el código al lector.

Hay algunas cuestiones:

• la historia que contar es diferente para los diferentes grupos de interés/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 de compatibilidad con texto para imágenes;
• de los comentarios en el sistema de control de fuente uno puede derivar cómo se construyó el sistema. La historia debería ser cómo el sistema podría haber sido construido (con una perfecta visión retrospectiva).

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

Answer 6

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 a 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 entre la documentación y el código se escala linealmente con el tamaño del código.

Answer 7

"En general, la programación es Literate siendo sólo texto"

Falso.

Los diagramas están bien.

Mi idea sería utilizar LP para especificar los componentes que se comunican entre sí utilizando evento arroyos

Eso es simplemente la 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 de ella realmente 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 base

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

¿Por qué?

Diagramas de forma intencionada detalles de elide. Un diagrama es un resumen o una descripción general. Pero como fuente de código, los diagramas son terribles. Con el fin de proporcionar todos los los detalles, los diagramas se vuelven muy desordenados.

Pero un resumen del diagrama de algunas otras marcas de LP funcionará bien.

Answer 8

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 añadir comandos propios/macros (en Python), por ejemplo, para hacer la importación especial, por ejemplo, de VCS ... http://code.google.com/p/nano-lp