¿Por qué no es corriente la programación alfabetizada? [cerrado]

La programación literaria tiene buenos ideales. ¿Por qué crees que esto no es convencional? ¿Es porque no ha podido entregar?

Lo vi por primera vez en un libro de los escritos de Knuth, y pensé que se veía bien. Luego intenté usar la pantalla de programación literaria para comprender lo que estaba sucediendo en el programa, y ​​lo encontré más difícil de lo que parecía. Puede haber sido que estaba demasiado acostumbrado a revisar los listados de programas, pero me pareció confuso.

Luego miré el código fuente, y eso me apagó en ese momento. Tendría que aprender a escribir programas de una manera completamente nueva, con menos correspondencia entre el texto del programa y lo que vio el compilador, y no vio ningún beneficio correspondiente.

Además, las personas pueden escribir argumentos largos y convincentes de que el código está haciendo X cuando en realidad está haciendo Y, y me he encontrado con mi parte de comentarios engañosos. Desarrollé una afición por leer el código para ver lo que está haciendo bastante temprano. La programación alfabetizada es la antítesis de eso.

Culparía al efecto de red . Para que otras personas puedan editar su código y documentación, deben poder entenderlo.

Esto aleja a la gente de algo como cweb / noweb, porque usarlos requeriría que aprendas TeX y la sintaxis específica del programa además del lenguaje de programación que estás usando para el proyecto. Esto puede verse como una gran pérdida de tiempo, especialmente si no necesitan nada de la composición matemática que es un gran atractivo para TeX en primer lugar. (Y para muchos programadores de aplicaciones, realmente no lo necesitarán). En cambio, prefieren algo como los comentarios XML de Visual Studio, porque eso ya es popular y está bien establecido.

Los lugares en los que he visto despegar la programación alfabetizada son en computación científica / estadística, donde la mayoría de los programadores tienen una capacitación significativa (también conocida como doctorado) en matemáticas, CS o estadística, y por lo tanto ya están familiarizados con LaTeX. Es más probable que la documentación que escriben incluya muchas fórmulas complicadas que están mejor escritas en TeX, y es más probable que estén programando en R. La proporción de programadores R que saben sobre SWeave es definitivamente mucho más alta que, digamos, la proporción de programadores de C que saben acerca de cweb.

Me fascinaba el concepto de programación literaria a fines de los 90 mientras estudiaba, y todavía estoy intrigado con el enfoque de Knuths para la programación y la composición tipográfica. Nada más que lo mejor lo hará.

El sistema de programación Literate que Knuth diseñó hizo mucho, mucho más de lo que se ve de inmediato, es decir, superó muchas deficiencias en el lenguaje de programación subyacente que la herramienta de generación de código generó a partir del documento fuente de Knuths, es decir, Pascal estándar.

Para aquellos que tienen la suerte de no haber probado Standard Pascal, estos son algunos de los aspectos más destacados.

• Para que sea más fácil tener un compilador de un solo paso, la especificación del lenguaje dice que todas las declaraciones tienen que venir en cierto orden. 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 deben estar en ese orden". Esto significaba que no podía agrupar sus cosas lógicamente en el archivo fuente.
• El manejo de las cuerdas fue más tedioso que en la C.
• Los identificadores no pueden tener una longitud arbitraria.
• Muchas cosas más que ya no puedo recordar.

Básicamente, todas estas cosas significaban que Knuth necesitaba un mejor lenguaje de programación (así que él inventó uno) y utilizaba Pascal como lenguaje ensamblador.

La mayoría de los lenguajes modernos pueden hacer estas cosas sin mucho esfuerzo, por lo tanto, eliminan una GRAN parte del trabajo que Literate Programming debía resolver.

Además, los lenguajes modernos son más expresivos, lo que permite pensar más en el código mismo.

Entonces, ¿qué queda? La capacidad de generar una forma de documentación tipográfica a partir del código fuente, y ESO existe hoy.

Solo piense en JavaDoc: la API de tiempo de ejecución de Java es quizás la pieza más grande de programación literaria disponible en la actualidad (excepto que el código no se presenta realmente, pero PODRÍA haberlo sido si Java fue de origen abierto desde el principio). Ver, por ejemplo, la presentación del marco de colecciones en http://download.oracle.com/javase/6/docs/api/java/util/Collection.html

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

Una cosa que descubrí cuando tuve mi aventura con la programación alfabetizada en los años 90 fue que atraía a personas muy apasionadas que querían hacer Exactamente lo correcto, y eso implicaba escribir su propio sistema de programación alfabetizada porque ninguno existente era lo suficientemente bueno para ellos. noweb fue un buen intento de cortar eso al proporcionar un denominador común lo suficientemente bueno para todos, aunque incluso entonces, pasé la mayor parte de mi tiempo LP desarrollando una bonita impresora para ello ...

Otro problema es que es realmente anti-ágil. De alguna manera, ser más lento es bueno porque te obliga a pensar de manera más directa y hacer las cosas bien la primera vez. Por otro lado, documentar meticulosamente a medida que avanza significa que hay una gran barrera para refactorizar su código. Y si espera hasta que su código se endurezca antes de LP-ify, termina con una tarea de documentación de varios días, que realmente puede detenerlo en seco.

En mis humildes opiniones, muchas empresas tienen una cultura que es lo opuesto a los objetivos de la programación literaria: quieren resultados más rápidos (solo lloran por la calidad cuando la aplicación está en producción). Según mi propia experiencia, mis jefes se negaron a comprender que los resultados más rápidos no significan "un programa ejecutable el día después de que lo pida". Para ellos, si un desarrollador no está ocupado escribiendo sobre su teclado, no está trabajando, está "perdiendo su tiempo en el diseño sin sentido". Sí, lo sé, mi jefe es un gilipollas.

Los codificadores escriben código no inglés.

A los codificadores no les gusta escribir documentación porque no ayuda a ejecutar el código.

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

La programación literaria parece ser la idea de llevar la documentación al siguiente nivel, donde el código es más un pensamiento posterior. Tal vez funcionaría, pero para la mayoría de los programadores parece una documentación desagradable.

Principalmente porque las personas son MUY ESTÚPIDAS. Un testimonio obvio de lo cual es un flujo interminable de conjeturas y malentendidos expresados ​​por los jóvenes sobre la naturaleza de esta técnica simple.

Las personas consideran que LP es: (a) un método de documentación (b) un método para escribir algunos ensayos pulidos que requieren algunas habilidades o talentos especiales (c) simplemente no tienen idea - como el creador del editor de programación Leo, por su propia admisión etc. etc. etc.

Sin embargo, LP es simplemente: (1) escribir programas en una mezcla de código y frases en un lenguaje humano (= cualquier), donde este último representa otros fragmentos de código y / o frases incluidas. Esto es precisamente lo que hacen los autores de innumerables libros de texto de programación ... y (2) es un simple preprocesador que expande esas frases en humanos (que se convirtieron en nombres de subrutinas incluidas) para desentrañar el resultado EN EL PEDIDO REQUERIDO POR EL COMPILADOR (o Interprete). De lo contrario, se puede ampliar el texto escrito con otra pequeña utilidad para incluir símbolos de formato para convertir la "fuente alfabetizada" en un texto agradable y bien formateado.

Los jóvenes nunca prueban esta idea extremadamente simple, y fantasean o imaginan razones falsas por las que nunca lo intentarán o lo harán.

Básicamente, la idea principal de programar "en pseudocódigo" escrito en un lenguaje humano y luego expandirlo con una sencilla utilidad de preprocesador AYUDA A GESTIONAR LA ATENCIÓN (limitada, una dificultad principal para cualquier programa largo), más o menos como el plegado de código o la división del flujo de su programa en funciones / subrutinas, necesarias para que no te pierdas en los detalles, pero totalmente innecesario para la ejecución de la máquina.

Hay 2 aspectos de la programación literaria que yo no deseo se incorporaron en la programación principal - las imágenes incorporado (por ejemplo, diagramas de diseño) y punteros a los intentos anteriores y alternativos (por ejemplo, "La razón es como esto se debe a que probé este otro lado y no funcionó porque ... "). Ambos aspectos pueden manejarse con comentarios de documentos y URI.

Porque la lógica de los programas no funciona igual que nosotros. Un programa tiene un flujo, condiciones y bucles bien especificados.

Después de haber codificado mucho, PIENSO en estos términos. Mi cerebro transforma los problemas en el dominio objetivo del código ejecutable. Y es mucho más eficiente para mí escribir esto en un lenguaje de programación generalmente, que tener que hacer el paso de transformación adicional para que mis programas sepan leer y escribir.

De hecho, creo que mis programas ya están alfabetizados ... identificadores de voz, buenos nombres de funciones, comentarios en los que hice alguna piratería que no comprendería inmediatamente después de unos meses.

Para concluir: mi código Java está más alfabetizado por sí mismo, como toda programación "alfabetizada" quiere ser.

Llegué a la programación alfabetizada al revés: soñé con organizar el código según me convenga, no como lo requiere el compilador. Leo encontré casi ideal para este propósito. También es compatible con el seguimiento de archivos modificados en el exterior. Estos archivos no tienen que contener ningún marcado especial, por lo que puedo usar Leo para mí sin necesidad de que otros miembros del equipo lo sepan. Esta característica - "@shadow trees" - es muy prometedora, aunque todavía tiene errores, necesita más globos oculares. Y también corrige el problema de "oh no, todo en un archivo grande", organizando todo en un esquema de árbol y apoyando archivos externos.

Para mí, al contrario del nombre, la "programación alfabetizada" no se trata en absoluto de documentación. No tengo más documentación que antes. Se trata de tener una estructura que me ayude a no perderme . Lo juro especialmente al administrar archivos JSP gigantes (y que a pesar de que Leo originalmente estaba destinado principalmente a Python y no tiene soporte para el lenguaje JSP, ¡tengo que dividir el archivo en el árbol Leo manualmente!).

Lo veo como una valiosa herramienta de enseñanza, donde se puede escribir una disertación sobre el código, y luego fragmentos de código de trabajo intercalados para instruir a los lectores sobre cómo, qué y por qué del código.

Fuera de un entorno puramente educativo, creo que solo Knuth realmente entiende la mejor manera de usarlo.

Es el peor de todos los mundos: debe escribir un programa de computadora altamente correcto y altamente específico en un idioma muy específico = inglés. Por lo tanto, debe escribirlo cuidadosamente usando exactamente las frases correctas, por lo que también podría simplemente escribir el código.