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

32

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

Casebash
fuente
2
Porque las herramientas que se desarrollaron para ello todavía son bastante débiles. Microsoft probablemente tiene una posibilidad de liderar en este sentido.
Trabajo
3
Al abordar un nuevo problema, a menudo uso mi propia taquigrafía de "Programación literaria" con lápiz y papel. Me permite ignorar la semántica del lenguaje y mezclar el lenguaje humano para describir las cosas que se
llamarán
1
Incluso Knuth ya no está convencido de este concepto: "Y estamos abandonando la vieja noción de" programación alfabetizada "que utilicé al desarrollar TEX82, porque la documentación ha resultado ser demasiado dolorosa". tug.org/TUGboat/tb31-2/tb98knut.pdf .
h0b0
66
Para aquellos que no están familiarizados con TeX y su filosofía, debe mencionarse que la cita de Knuth probablemente signifique irónicamente.
3
@ h0b0 & user1249: todo el artículo de Knuth es irónico, como puede descubrir simplemente leyendo. También se burla de Steve Jobs, la web, Agile, refactorización, OOP, AOP y muchas otras cosas. ¡Es una broma!
Andres F.

Respuestas:

35

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.

David Thornley
fuente
44
La programación alfabetizada, así como los comentarios en general, no se trata de lo que está haciendo su código. Puedes leer eso desde el código mismo. Se trata de por qué y cómo , y esta información esencial casi siempre falta sin una programación adecuada. No es necesario mencionar que la parte del " ¿por qué? " A menudo implicaría matemáticas complejas y complicadas, a veces diagramas y tablas, a veces diagramas. Se necesitan herramientas de programación alfabetizadas para mantener dichos comentarios de forma legible.
SK-logic
1
@ SK-logic fair, pero el punto que David Thornley está haciendo es que incluso el POR QUÉ puede llegar a ser una mentira engañosa (una que en realidad es aún más difícil de comprender).
MrFox
1
+1 Knuth estaba escribiendo en los días de programación (temáticos) del salvaje oeste cuando trabajaba en un lenguaje "avanzado" significaba escribir "C" casi encima del metal en lugar de usar código de máquina. La memoria era variables muy ajustadas y otros nombres solían ser letras simples, a menudo reutilizadas de un alcance a otro. La gran mayoría de los programas fueron tomas llave en mano escritas y mantenidas por una persona, cada una con su propio estilo excéntrico. Tener que hacerse cargo de una base de código fue más descifrado que leer. No había control de fuente, etc. para ayudar.
TechZen
1
Knuth estaba mirando el camino, hace 30 años hoy. Sabía que los programas se harían más grandes, más complicados, serían escritos por equipos con miembros cambiantes, se ejecutarían durante años o décadas y requerirían aportes, evaluaciones y, finalmente, la aceptación de los no programadores. La programación alfabetizada fue una idea para abordar todo eso. Estaba criticando lo que hoy llamamos lógica comercial y BDD. La idea central es que los programadores sabrían qué hacer y los que no son programadores podrían seguirlo. Como se señaló, la idea fracasó porque no existe ningún mecanismo para imponer el vínculo entre el texto "alfabetizado" y el código.
TechZen
Por cierto: por eso me gustan los lenguajes de "autodocumentación" como Objective-C. Al principio, el código parece estar abarrotado de nombres de métodos absurdamente largos, pero incluso un programador que no conoce el lenguaje o la API puede descifrar rápidamente qué está haciendo el código. Lo mejor de todo, cambie el código y los "comentarios" cambian en sincronización automáticamente. Por supuesto, por eso Objective-C fue escrito con autocompletado incorporado. Sin él, escribir Objective-C es bastante infernal.
TechZen
13

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.

Larry Wang
fuente
2
Esta respuesta parece suponer que todas las herramientas de programación alfabetizadas están utilizando LaTeX. ¿Es esto cierto? No parece haber nada sobre el concepto que lo requiera.
AShelly
@AShelly: No es obligatorio. Sé que noweb, al menos, te permite usar HTML. Pero en la práctica, las personas que escriben documentación HTML usarán javadoc y similares en lugar de herramientas de programación alfabetizadas.
Larry Wang
1
@AShelly, para que la programación alfabetizada funcione, debe poder generar el documento que se imprimirá. Esto es mucho más fácil cuando el formato está basado en texto, y que yo sepa, el formateador de documentos basado en texto más poderoso es TeX, y la forma más fácil de trabajar con TeX es usando LaTeX.
@AShelly, quizás quieras echar un vistazo al org-modesoporte de programación alfabetizada . Es bastante útil, y me resulta mucho más fácil de comprender (sin mencionar administrar ) que WEB o NOWEB solo. Un aspecto importante del código es la legibilidad, y esto es legible. (cf github.com/vermiculus/stack-mode )
Sean Allred
12

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.


fuente
To make it possible to have a single-pass compiler, all declarations had to come in a certain order. Una orden de declaración como esa ciertamente simplifica el diseño del compilador, pero no habilita / impide la compilación de un solo paso. Delphi, por ejemplo, no tiene esa restricción de orden, pero sigue siendo un compilador Pascal estrictamente de un solo paso.
Mason Wheeler
Convenido. Turbo Pascal tampoco tenía esta restricción. Sin embargo, tenga en cuenta que esta restricción estaba en la definición de Pascal desde el principio.
1
No, Knuth cambió a CWEB hace mucho tiempo, no se trata de corregir las deficiencias de Pascal. No, JavaDoc no tiene nada que ver con la "programación alfabetizada" de Knuth: está hablando de cambiar fundamentalmente la forma en que crea el código, y afirma que le permite abordar la complejidad que, de lo contrario, afirma que de otra forma no sería posible para él o para cualquier otra persona.
Ron Burk
@RonBurk CWEB simplemente compila a un mejor "lenguaje ensamblador". Esto no invalida las decisiones de diseño originales.
Thorbjørn Ravn Andersen
5

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.

dfan
fuente
Después de experimentar, descubrí que el punto óptimo del LP para el resto de nosotros podría estar en documentar las decisiones de diseño y los detalles de la arquitectura justo al lado del código real. Estoy de acuerdo con que LP es más difícil de refactorizar. Entiendo que Knuth hizo el diseño inicial en papel y solo cuando estaba satisfecho comenzó la implementación real. Esta es probablemente la misma situación que encuentro que funciona para mí.
Thorbjørn Ravn Andersen
3

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.

Nisanio
fuente
Luego, con la programación literaria, ¡podrían pensar que estás ocupado escribiendo un libro de ciencia ficción en lugar de otro software! : D
Mahdi
Compañías como esa no entienden que un buen software vive mucho tiempo y cuanto mejor documentación, más vale la fuente.
Thorbjørn Ravn Andersen
2

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.

Winston Ewert
fuente
29
Los codificadores que se adhieren a los puntos que usted describe no son codificadores con los que quiero trabajar conmigo.
Paul Nathan
1
@Paul, concedido. Pero eso es lo que hay realmente ahí fuera. Pero me parece que más documentación no es necesariamente mejor.
Winston Ewert el
1
suficiente es posiblemente el mejor
mlvljr
66
los programadores experimentados saben que NECESITAN escribir documentación porque ahí es donde va el "POR QUÉ lo hice así".
1
@ Thorbjørn Ravn Andersen, sí, eso es cierto. Pero la programación alfabetizada, (según tengo entendido) sugiere que escriba código con su documentación en lugar de documentación con su código. ¿Esa documentación es realmente útil?
Winston Ewert
2

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.


fuente
3
Te falta un bit importante: (3) una forma de reordenar un código en cualquier idioma en la secuencia más legible y natural, que no es necesariamente el mismo orden con el que tiene que lidiar un compilador. Incluye ocultar los detalles de implementación en notas al pie o en cualquier otro lugar lejos del esquema del código.
SK-logic
1

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.

Larry OBrien
fuente
1

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.

Daniel
fuente
2
Un código Java no puede leer y escribir. Sus "identificadores de voz" nunca explicarán por qué elige este algoritmo en particular sobre otro, cuáles son los límites, cuál era su expectativa de perfil de rendimiento, etc. Mis programas alfabetizados están compuestos principalmente de fórmulas, diagramas y gráficos, y no tanto texto en inglés. Pero todo eso no se puede expresar en un código y parece feo dentro de comentarios simples.
SK-logic
1

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!).

Juraj
fuente
0

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.

Greyfade
fuente
-4

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.

Martin Beckett
fuente
3
No debe repetir su código en inglés. Los comentarios deben explicar la razón por la cual el código está allí, no lo que está haciendo. A menudo incluyo gráficos, diagramas y diagramas en mis comentarios literarios, y realmente ayuda a entender el código.
SK-logic
Si los comentarios no dicen qué está haciendo el código, entonces, ¿cómo es la programación alfabetizada? Es solo una programación regular con comentarios. Pensé que el objetivo de la programación alfabetizada era describir el programa en los documentos y hacer que el sistema generara código a partir de la documentación.
Martin Beckett
3
intenta leer "TeX, el programa". El código nunca se repite en los comentarios allí. Los comentarios explican por qué el código está escrito de esa manera y explican la arquitectura.
SK-logic
3
@MartinBeckett Lo que describe no es LP.
Andres F.