it-swarm-es.com

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

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

32
Casebash

Lo vi por primera vez en un libro de 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.

35
David Thornley

Culparía a 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 informática 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 se escriben mejor 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 mayor que, digamos, el proporción de programadores de C que saben acerca de cweb.

13
Larry Wang

Me fascinaba el concepto de programación literaria a fines de los años 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 hará.

El sistema de programación Literate que diseñó Knuth hizo mucho, mucho más de lo que parece a simple vista, 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 podría no agrupar sus cosas lógicamente en el archivo fuente.
  • El manejo de las cuerdas fue más tedioso que en el plano 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, eliminando 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 desde el código fuente, y [~ # ~] que [~ # ~] existe hoy.

Solo piense en JavaDoc: la API Java runtime API 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 haber sido si Java fue abierto desde el principio). Vea, 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.

12
user1249

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.

5
dfan

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

3
Nisanio

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.

2
Winston Ewert

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 como si fueran nombres de subrutinas incluidas) para desentrañar el resultado EN EL PEDIDO REQUERIDO POR EL COMPILADOR (o Interprete). De lo contrario, se puede expandir 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.

2
user19562

Llegué a la programación alfabetizada al revés: soñé con tener el código organizado según me convenga, no como lo requiere el compilador. Encontré Leo casi ideal para este propósito. También es compatible con el seguimiento de los archivos modificados fuera. 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 soluciona el problema "oh no, todo en un archivo grande", organizando todo en el esquema del á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 eso 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) !).

1
Juraj

Hay dos aspectos de la programación alfabetizada que I do deseo se incorporaron a la programación convencional: imágenes incrustadas (p. Ej., Diagramas de diseño) e indicadores para intentos anteriores y alternativos (p. Ej., "La razón por la que es así es porque intenté esto de otra manera y no funcionó porque ... "). Ambos aspectos se pueden manejar con comentarios de documentos y URI.

1
Larry OBrien

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 Java está más alfabetizado por sí mismo como lo quiere toda programación "alfabetizada".

1
Daniel

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.

0
greyfade