¿Por qué no se la programación ilustrada corriente principal? [cerrado]

Question

Literate programación tiene buenos ideales. ¿Por qué cree que esto no es la corriente principal? Es porque se ha podido entregar?

Answer 1

vi por primera vez en un libro de escritos de Knuth, y pareció que estaba limpio. Luego trató de utilizar la pantalla de programación literaria de comprender lo que estaba pasando en el programa, y ??descubrí que es más difícil de lo que parecía. Puede haber sido que yo estaba demasiado acostumbrado a ir por listas de programas, pero parecía confuso.

Luego miró el código fuente, y eso me apagado en ese momento. Tendría que aprender a escribir programas de una forma completamente nueva, con menos correspondencia entre el texto del programa y lo que el compilador de sierra y sierra sin beneficio correspondiente.

Además, la gente puede escribir largo y convincentes argumentos de que el código está haciendo X cuando en realidad está haciendo Y, y me he encontrado mi parte de engañar a los comentarios. He desarrollado una afición por la lectura del código para ver lo que está haciendo bastante temprano. Programación literaria es la antítesis de eso.

Answer 2

Me culparía al efecto de red . Para otras personas a editar el código y la documentación, que debe ser capaz de entenderlo.

Esto empuja a la gente lejos de algo así como cweb / noweb, debido a su uso requeriría que aprender TeX y la sintaxis específica del programa en la parte superior del lenguaje de programación que está utilizando para el proyecto. Esto puede ser visto como una enorme pérdida de tiempo, especialmente si ellos no necesitan ninguno de los archivos de texto de matemáticas que es una gran atracción para tales TeX en el primer lugar. (Y para muchos programadores de aplicaciones, que en realidad no lo necesitaremos.) En su lugar, prefieren algo así como los comentarios XML de Visual Studio, porque eso es ya popular y bien establecida.

Los lugares que he visto programación literaria despegar están en la computación científica / estadístico, donde la mayoría de los programadores tienen una formación significativa (también conocido como doctorados) en matemáticas, CS o estadísticas, y por lo tanto ya famliiar con látex son. La documentación que escriben es más probable que incluyen una gran cantidad de fórmulas complicadas que están mejor escritas en TeX, y son más propensos a ser la programación en R. La proporción de programadores que saben de R Sweave es sin duda mucho mayor que, por ejemplo, la proporción de los programadores de C que saben de cweb.

Answer 3

Yo estaba fascinado por el concepto de programación Literate a finales de los 90'es mientras se estudia, y todavía estoy intrigado con el enfoque Knuths a la programación, y archivos de texto. Nada más que lo mejor va a hacer.

El sistema de programación literaria que Knuth diseñado hizo mucho, mucho más de lo que de inmediato el ojo, es decir que superar muchas deficiencias en el lenguaje de programación subyacente de que la herramienta de generación de código generado a partir del documento fuente Knuths, a saber Pascal estándar.

Para los afortunados que no han intentado Pascal estándar, aquí están algunos de los aspectos más destacados.

• Para que sea más fácil tener un compilador de una sola pasada, la especificación del lenguaje dicho que todas las declaraciones tenían que llegar en un orden determinado. Desde la página de Wikipedia: "Cada procedimiento o función puede tener sus propias declaraciones de Goto etiquetas, constantes, tipos, variables y otros procedimientos y funciones, que todos deben estar en ese orden." Esto significaba que se podía no agrupar las cosas de forma lógica en el archivo de origen.
• manejo de cadenas era más tedioso que en la llanura C.
• Identificadores no podían tener una longitud arbitraria.
• Muchas más cosas que no recuerdo más.

Todas estas cosas básicamente significaba que Knuth necesitaba un mejor lenguaje de programación (por lo inventó uno) y se utiliza Pascal como lenguaje ensamblador.

La mayoría de las lenguas modernas puede hacer estas cosas sin mucho esfuerzo, por lo tanto, la eliminación de una gran parte del trabajo que sabe leer y escribir eran Programación de resolver.

También lenguas modernas son más expresivos que permite más pensado para ser puesto en el propio código.

Por lo tanto, lo que queda? La capacidad de generar una forma tipográfica de la documentación del código fuente, y que existe hoy en día.

Sólo piensa JavaDoc - la API de ejecución de Java es quizás la pieza más grande de Literate de programación disponibles en la actualidad (a excepción de que el código no se presenta en realidad, pero que podría haber sido si Java estaba abierta de origen desde el principio). Véase, por ejemplo, la presentación del marco de las colecciones de http://download.oracle. com / JavaSE / 6 / docs / api / java / util / Collection.html

Creo que existen sistemas similares para .NET y otros programas principales.

Answer 4

Una cosa que descubrí cuando tuve mi aventura con la programación ilustrada en los años 90 fue que atrajo a gente muy apasionada que querían hacer exactamente lo correcto - y que supone la renuncia a su propio sistema de programación literaria porque nadie existente era lo suficientemente bueno para ellos. noweb fue un buen intento de corte que fuera proporcionando una suficientemente buena mínimo común denominador para todos, aunque incluso entonces, pasé la mayor parte del tiempo el desarrollo de un LP muy-impresora para que ...

Otra cuestión es que es muy anti-ágil. En cierto modo, de estar enlentecido es bueno porque te obliga a pensar más por adelantado y hacer las cosas bien la primera vez. Por otro lado, documentando meticulosamente a medida que avanza significa que hay una gran barrera para la refactorización su código. Y si usted espera hasta que su código se endurece antes de LP-ify ella, usted termina con una tarea de documentación de varios días, lo que realmente se puede detener en sus pistas.

Answer 5

En mi humilde opinión, muchas empresas tienen una cultura que es lo contrario a los objetivos de programación Literate: quieren resultados más rápidos (sólo lloran sobre la calidad cuando la aplicación está en producción). En mi propia experiencia, mis jefes tenían basura a entender que los resultados más rápidos no significa "un programa ejecutable al día siguiente de pedir." Para ellos, si un desarrollador no está ocupado escribiendo sobre su teclado, no está trabajando, está "perdiendo el tiempo en el diseño de la no-sentido". Sí, lo sé, mi jefe es un culo.

Answer 6

Los codificadores de código de escritura no Inglés.

Los codificadores no les gusta escribir documentación, ya que no ayuda a la ejecución de código.

Los codificadores no son buenos para escribir documentación porque es un medio pobre para expresar sus ideas.

Programación literaria parece ser la idea de llevar la documentación al siguiente nivel en el que el código es más de un pensamiento-después. Tal vez que iba a funcionar, pero a la mayoría codificador parece que la documentación desagradable.

Answer 7

Principalmente porque las personas son muy estúpidos. testimonio evidente de que es un sinfín de conjeturas y malentendidos expresados ??por los jóvenes acerca de la naturaleza de esta técnica simple.

La gente toma LP a ser: (a) un método de documentación (b) un método para escribir algunos ensayos pulido que requiere algunas habilidades especiales o talentos (c) simplemente no tienen ni idea - como el creador del editor de programación Leo, por su propia admisión, etc, etc, etc.

Sin embargo LP es simplemente: (1) la escritura de programas en una mezcla de código y frases en un (= ninguna) el lenguaje humano, cuando éste soporte para otras partes del código y / o frases incluidas. Esto es precisamente lo que los autores de libros de texto de programación innumerous hacen .. y (2) es un preprocesador simple que se expande esas frases en humanos (que se convirtió como si los nombres de subrutinas incluidos) para desentrañar el resultado en el orden requerido por el compilador (o Interprete). De lo contrario se puede ampliar el texto escrito con otra pequeña utilidad para incluir formato de símbolos para convertir la "fuente leer y escribir" en un agradable buen formato de texto legible.

Los jóvenes no intente esto extremadamente simple idea -. Y, o bien fantasear o imaginar razones falsas por qué nunca se van a tratar o lo hacen

Básicamente, la idea principal de la programación "en pseudocódigo" escrito en un lenguaje humano y luego expandirlo con una sencilla utilidad preprocesador ayuda a gestionar la atención (limitado, una dificultad principal para cualquier programa bastante largo), más o menos como el plegado de código o división de el flujo de programa en funciones / subrutinas, necesaria para que no pueda perderse en los detalles, pero totalmente innecesario para la ejecución de la máquina.

Answer 8

There are 2 aspects of literate programming that I do wish were incorporated into mainstream programming -- embedded imagery (e.g., design diagrams) and pointers to previous and alternate attempts (e.g., "The reason it's like this is because I tried this other way and it didn't work because ..."). Both of those aspects can be handled with doc-comments and URIs.

Answer 9

Because the logic of programs does not work the same as we speak. A program has a well specified flow, and conditions, and loops.

After having coding at lot, I THINK in these terms. My brain transforms problems into the target domain of executable code. And it is much more efficient for me to write this down in a usually programming language, than having to do the extra transform step to make my programs literate.

In fact, I believe my programs already are literate... speaking identifiers, good function names, comments where I did some hackery which i wouldn't comprehend immediately myself after a few months.

To conclude: My Java code is more literate by itself as every "literate" programming wants to be.

Answer 10

I came to literate programming the other way around - I dreamed having the code organized as it fits my mind, not as the compiler requires it. I found Leo almost ideal for this purpose. It also supports keeping track of files changed outside. These files do not have to contain any special markup, so I can use Leo for myself without any need for others in the team to know. This feature - "@shadow trees" - is very promising, although still bit buggy, needs more eyeballs. And it also fixes the "oh no, everything in one big file" problem both by organizing everything into tree outline and by support for external files.

For me, contrary to the name, the "literate programming" is not about documentation at all. I don't have more documentation than before. It is about having structure that helps me to not become lost. I swear by it especially when managing behemoth JSP files (and that despite Leo was originally intended primarily for Python and it does not have support for JSP language - I have to split the file to Leo tree manually !).

Answer 11

I see it as a valuable teaching tool, where a dissertation on code can be written, and then snippets of working code interleaved in it to instruct readers on the hows, whats, and whys of the code.

Outside a purely educational environment, I think only Knuth really understands how best to use it.

Answer 12

It's the worst of all worlds - you have to write a highly correct, highly specific computer program in a very non-specific language = english. So you have to carefully write it using exactly the correct phrases - so you might as well just write code.