motivación intuitiva para Literate programación?

Question

Por lo tanto, he usado el garabato / lp módulo de escribir mi primer programa de leer y escribir usando PLT-esquema:

#lang scribble/lp
(require scribble/lp)

<<lp_scheme.ss>>

@chunk[<squarefunction>
        (define (f x)
         (* x x))]

No hay nada útil allí, por supuesto. Ahora estoy especie de preguntando ¿por qué simplemente no utilizar los comentarios de fricción, en lugar de construcciones de programación literaria. Se aceptan todas las opiniones. Sería muy bueno si alguien que probablemente ha tenido más exposición / exp. con ella, posiblemente, para dar una explicación más intuitiva de las diferencias entre un código bien documentado y código escrito utilizando construcciones de programación literaria.

Answer 1

(estoy asumiendo que usted está utilizando la definición de la programación literaria de Donald Knuth.)

La diferencia clave es uno de los secuencia .

Al escribir una aplicación normal, hay restricciones en el orden en que se expresan las cosas.

Para ilustrar:

• Todo el código para una clase particular tiene que ser expresadas en un solo lugar
  (O en un número muy pequeño de lugares, por ejemplo, C # clases parciales)
• Todo el código de un método tiene que ser dada en una sola vez, en el orden correcto para la ejecución
• Las dependencias deben ser declaradas antes dependiente de las cosas sobre ellos
  (Las variables declaradas antes de su uso en la mayoría de los idiomas; los procedimientos / funciones declaradas antes de su uso en Pascal; ensamblados compilados biblioteca antes que otros en .NET)

Con programación literaria que se libera de esta restricción y liberados para expresar sus conceptos en cualquier orden lógico para que pueda utilizar la hora de explicar el programa a otro desarrollador.

Esto tiene otra consecuencia - en algunas formas, se puede expresar un concepto, una vez (por ejemplo, "Todas las propiedades se disparará el evento PropertyChanged cuando cambian"), y tienen que tejida a través de su aplicación en una miríada de otros lugares.

Para los programas muy simples, un programa de leer y escribir y una bien comentado podrían tener el mismo aspecto -. Pero a medida que la complejidad del sistema crece, los dos empezarán a aparecer muy diferente

Answer 2

motivación principal, en cuanto a mí, es que cada programador uso de hojas de papel / cuaderno a la arquitectura 'diseño', desarrollar ideas, hay que escribe esquemas, diagramas, tratan algunos cálculos y así sucesivamente. Después de terminar el programa, todos estos cuadernos hojas / papel se pierden, por lo que la capacidad de soporte del programa se está abajo. Escribí sobre esto en WiKi de mi NanoLP herramienta LP: http://code.google .com / p / nano-lp / wiki / AboutLP .

En segundo lugar la motivación, no tan explícitamente, es errores menores. Pero esto no es lo 'teórico', que es la experiencia hecho (para mí) - cuando se está pensando '' en el papel, dibujar diagramas, esquemas de algoritmos - el programa habrá errores menores. LP es tal 'papel', nada más.

Hay muchos desarrolladores, que nunca se dibuja algo, incluso sin comentarios (!), Que escriben programa sólo ... Terrible!

Y LP le ayuda a crear una buena documentación (no en modo formal - Descripción de funciones, es args, y lo que devuelve, y seguro que esto es más conocido con firma de la función, así que por qué es necesaria dicha documentación ??), pero que ayuda a escribir documentación REAL REAL con semántica, con imágenes, con la descripción de las acciones reales ...

Muchas motivaciones :) y seguro a veces es mejor usar único LP inversa (Doxygen, por ejemplo), a veces -. LP real depende de muchos factores

Answer 3

Programación literaria se basa en tres simples declaraciones:

1. Los programadores deben escribir código, que la computadora pueda entender
2. Los programadores deben escribir documentación, que la gente puede entender
3. Si se trata de documentos separados, es inevitable que van a estar fuera de sincronización

De hecho, en mi experiencia, # 2 por lo general se subestima. He perdido la cuenta de cuántas veces me ha dicho control de calidad "el doctor dice esto, pero el código hace eso; es el código incorrecto o es el doc fuera de fecha?" No espero que mi lugar de trabajo está fuera de lo común, en ese sentido. Además, en uno de mis primeros proyectos, que estaba tratando de mantener la documentación hasta a la fecha que el de ida y vuelta con las partes interesadas dieron lugar a cambios en los requisitos. Esto fue lo suficientemente mucho tiempo y que me dijeron, por la administración, a dejar de jugar con los documentos y acaba de obtener el trabajo del proyecto. Hemos ido a los procesos de documentación menos tediosas, desde entonces (gracias a Dios!).

Tenemos herramientas de revisión de código, donde, cuando hacemos un cambio en el código, varias personas pueden ver los cambios, claramente definidos, y pueden hacer comentarios, hacer preguntas, explicando cosas, ofreciendo mejoras. Si el código fue escrito con técnicas de programación literaria, gran parte de esta pregunta / respuesta sería superfluo porque se incluiría la explicación.

La mayor parte de la mentalidad de la programación moderna es que el código debe ser su propia documentación. Muchos expertos sostienen que, si ves que necesitas para explicar su código en los comentarios, probablemente debería cambiar el formato del código (cambio de nombres de variables / funciones, etc.) de tal manera que los comentarios son innecesarios. Me parece que esto es muy bien en teoría, menos práctica en la realidad. Es decir, cuando estoy usando bibliotecas creadas / mantenidas por otra persona, su elección del método / nombres de función no siempre es intuitivo para mí. Por ejemplo:

Set<String> statesWeCareABout = new HashSet<String>(Arrays.asList(new String[] { "one", "two", "three" }));
Set<String> statesWeFound = <some function>;
statesWeFound.retainAll(statesWeCareAbout);

Si usted no está familiarizado con el conjunto <> o HashSet <>, puede que no sepa que .retainAll () significa dame la intersección de los dos, con el resultado en el conjunto modificado <>.

Por último, letrado de programación por lo general le permite romper las cosas para que pueda explicar esta pieza de código de forma aislada, a continuación, en línea en esta otra pieza de código. Esto está más en línea con el funcionamiento de la comprensión humana. Me explique cómo funciona esto, a continuación, construir en ese entendimiento para explicar la imagen más grande. Las computadoras no les importa; se puede escribir una sola función con 1.000 líneas de código y no tiene ningún problema en la comprensión de todo el asunto. Dios le ayudará si usted, como desarrollador, tiene que mantener eso.

Y que, en definitiva, es el razonamiento detrás de Literate programación. Código tendrá que ser mantenido, si se trata de errores que se fijan o características que se agregan. Y si no puede ser comprendido por otra persona, más adelante, de una manera eficiente, que será sustituido. No hay manera de mucho "sólo escribir" código en este mundo. Programación literaria hace que sea más fácil de leer y comprender, lo que hace que sea más probable que se mantenga y se utiliza, a largo plazo.

Y realmente tenemos tiempo para mantener reinventar la rueda?