Programación alfabetizada, metodología de diseño buena / mala


10

Recientemente he encontrado el concepto de programación alfabetizada . Y lo encontré bastante intrigante. Sin embargo, no me han encontrado afirmaciones de que sea una mala forma de estructurar un programa. Parece que no cubre muchos lugares. Ni siquiera aquí pude encontrar alguna pregunta al respecto.

Mi pregunta no es sobre sus defectos o formas de manejar la documentación. Considero que la documentación es un efecto secundario de lo que significaría para el flujo de la programación alfabetizada. Sé que el diseño fue originalmente diseñado para facilitar la documentación, así como el concepto de flujo de programación hacia adelante .

El concepto de dividir el problema en problemas basados ​​en oraciones pequeñas parece ser realmente una idea brillante. Así facilitará la comprensión del flujo del programa.

Una consecuencia del método de diseño alfabetizado es también que el número de funciones requeridas se limitará a la imaginación del programador. En lugar de definir una función para una tarea determinada, podría crearse como un scrapmétodo alfabetizado. Esto produciría una inserción automática del código, en lugar de una compilación de funciones separada y el requisito posterior de un paso de optimización de compilación entre procedimientos para obtener la velocidad equivalente. De hecho, el primer intento de Donald E. Knuth mostró un tiempo de ejecución inferior, debido a este mismo hecho. Sé que se pueden hacer muchos compiladores para esto, sin embargo, esta no es mi preocupación.

Entonces, ¿me gustaría recibir comentarios sobre por qué uno debería considerar esta una metodología de diseño mala / buena?


2
Zeroth, creé la etiqueta de programación alfabetizada y agregué un resumen basado en el artículo de Wikipedia. Ayude a expandir la etiqueta wiki con información relevante.
Yannis

@ YannisRizos Lo agregaré aquí, no tengo privilegios de edición.
zeroth

1
Bueno, yo tampoco :) He agregado algunos recursos (el artículo de Wikipedia y los enlaces en su pregunta), aparecerán cuando la edición sea revisada y aceptada por pares (?!). Es un enfoque intrigante, y como ya lo está explorando, regrese y mejore la etiqueta wiki cada vez que encuentre algo que piense que vale la pena mencionar allí.
Yannis

1
Recomendaría al autor del sitio de Literate Programming que visite el sitio UX stackexchange; los colores son realmente malos para leer.
Danny Varod

1
Para su información, también hay una literate-programmingetiqueta en StackOverflow. Hay más contenido allí, aunque todavía no mucho.
Ross Patterson

Respuestas:


9

Esto produciría la inserción automática del código, en lugar de una compilación de funciones separada y el requisito posterior de un paso de optimización de compilación entre procedimientos para obtener la velocidad equivalente

Esto es irrelevante. Lo ha sido por décadas. Puede eliminarlo de la pregunta, ya que no tiene sentido que los compiladores modernos subviertan sus optimizadores.

Entonces, ¿me gustaría recibir comentarios sobre por qué uno debería considerar esta una metodología de diseño mala / buena?

No hay inconveniente en la programación alfabetizada. (Espero decenas de -1 votos por ese sentimiento). Como practicante, nunca he visto ningún problema.

Hay algunos argumentos contra los cuales todo equivale a "la programación en un lenguaje de nivel superior se subvierte ajustando el código resultante". Correcto. De la misma manera que la programación en C ++ se subvierte al modificar el .oarchivo que se produce. Es cierto, pero irrelevante.

Escribir programas alfabetizados simplemente significa combinar diseño de alto nivel y detallado (nivel de código) en un documento, escrito con un conjunto de herramientas adecuado que produce archivos compatibles con el compilador y archivos amigables para las personas.

Cuando Knuth inventó la programación alfabetizada, los lenguajes OO convencionales no existían. Por lo tanto, gran parte de las herramientas web y de tejido originales le permitieron crear definiciones de clase para tipos de datos abstractos.

Gran parte de eso es irrelevante hoy en día. Las herramientas de programación literaria pueden ser bastante simples si se centran en lenguajes de programación modernos, orientados a objetos (o funcionales) de alto nivel. Hay menos necesidad de soluciones elaboradas debido a las limitaciones de C (o Pascal o Assembler).

El enfoque para escribir programas alfabetizados no es diferente del enfoque para escribir programas analfabetos. Todavía requiere un diseño cuidadoso, pruebas unitarias y codificación ordenada. El único trabajo adicional es escribir explicaciones además de escribir código.

Solo por esta razón, la necesidad de escribir explicaciones coherentes, la programación alfabetizada es difícil para algunos programadores. Hay un buen número de programadores que tienen éxito (su código pasa todas las pruebas unitarias, es ordenado y fácil de entender) pero parece que no pueden escribir una oración coherente en su idioma nativo. No sé por qué esto es cierto.

Hay una gran cantidad de programadores que parecen tener un éxito marginal y luego solo por accidente. (Hay suficientes preguntas malas en Stack Overflow que indican que muchos programadores luchan incluso por comprender los fundamentos). Para los programadores que hacen preguntas de desbordamiento de pila en gran medida incoherentes, sabemos que realmente no pueden hacer un buen trabajo de programación alfabetizada, porque pueden No haga un buen trabajo de programación.


77
Una gran cantidad de programadores son apenas coherentes al explicar algo en cualquier medio, formal o informal, ya sea programación alfabetizada, escribir comentarios o incluso un correo electrónico. Es una maravilla que el software funcione en absoluto :)
Andres F.

3

El aspecto más importante de la programación alfabetizada (o incluso los buenos comentarios) para mí no es tanto que proporcione documentación, sino que indique la intención del programador. Al conocer la intención declarada, puede juzgar de inmediato si el código que sigue realmente cumple o no lo que debería. Sin intención, debe comenzar con la suposición de que el código es correcto y luego demostrar que es correcto o incorrecto por inducción, lo que es más agotador y requiere más tiempo, ya que a menudo también requiere familiarizarse con todo el código circundante.

Por lo tanto, la intención declarada a menudo permite a otras personas que no están familiarizadas con el código saltar rápidamente y encontrar errores sin tener que conocer el contexto más amplio que lo rodea.

Y, por supuesto, le ayuda a aprender el flujo básico y el diseño del código más rápido, ya que el inglés simple es a menudo más intuitivo que la aritmética de punteros para la mayoría de las personas.


1

Si bien soy bastante nuevo en el concepto de programación literaria (y, por lo tanto, es probable que me haya perdido el barco por completo), parece alinearse con el concepto de DSL .

La idea detrás de un DSL es desglosar un dominio de problemas en una gramática simple orientada al lenguaje natural que se pueda usar para construir algoritmos para resolver esos problemas.

Para mí, esa misma idea, o al menos la base fundamental de la misma, es la misma o al menos estrechamente relacionada con la programación alfabetizada.

En el mundo maravilloso, por ejemplo, existe un fuerte impulso para usar DSL más regularmente y para crear nuevas DSL para resolver problemas comunes. Este impulso proviene de ambas herramientas dentro del lenguaje (constructores fáciles), así como de bibliotecas centrales que admiten una API basada en DSL.

Dado que la tendencia, al menos en ese rincón del mundo, es hacia la programación alfabetizada, diría que es una buena metodología para luchar.

Desafortunadamente, el nivel de pensamiento necesario para crear un buen dsl está a menudo más allá de la mayoría de los programadores, por lo que he visto. Sé que personalmente lucho con algunos de los conceptos necesarios de vez en cuando. Puede ser esta dificultad la que ha impedido que tales técnicas obtengan una adopción más amplia.

Es el caso clásico de cuando usar la herramienta es una cosa, pero crearla está en un nivel completamente diferente.


Para ampliar un poco mi punto de vista, no es tanto que las DSL sean lo mismo que la programación alfabetizada, sino que hacen que la programación alfabetizada sea mucho más posible . Particularmente cuando son DSL de lenguaje natural .

En la versión 1.8 de groovy, la capacidad DSL en lenguaje natural se mejoró sustancialmente con la adición de cadenas de comandos más potentes.

Por ejemplo, las siguientes líneas de código son programación , no solo pseudo-oraciones:

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

Nota: el ejemplo de código proviene del blog de Guillaume Laforge

La idea central detrás de la programación alfabetizada es que el lenguaje natural es más comprensible para los humanos y eso es lo que importa. Las capacidades DSL de lenguaje natural de Groovy hacen que sea una realidad mucho más cercana, en mi opinión. Especialmente cuando esas DSL se utilizan para crear reglas comerciales para una aplicación.

Ser capaz de "codificar" los componentes críticos de un sistema utilizando lenguaje natural es la esencia misma de la programación alfabetizada. Tener que intercalar el lenguaje natural con fragmentos de código es una forma bastarda de programación alfabetizada. Si bien es útil, creo que las DSL de lenguaje natural que le permiten usar lenguaje natural como el código en sí mismo son un gran avance.

Ampliar la capacidad de programación en general es el siguiente paso en el proceso, pero en gran medida las herramientas para hacerlo ya están implementadas. Sí, todavía no hay un DSL "general", pero para dominios más pequeños, la capacidad está ahí.

Para obtener más ejemplos de esto en acción (sin ningún orden en particular):


2
Interesante punto de vista. Desde mi punto de vista, no se alinea muy bien con un DSL. Dado que la programación alfabetizada está en algún lenguaje no DSL. Y las herramientas tampoco son muy parecidas a las DSL. No están orientados hacia el dominio del problema. ¿Podría dar un ejemplo de cómo cree que la programación alfabetizada es como un DSL? Un enlace o una referencia a un ejemplo puede ayudar a aclarar su respuesta.
S.Lott

Un ejemplo de esto son las cadenas de comandos en Groovy 1.8 que le permiten "programar" con cosas como turn left then righto paint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/…
cdeszaq

@ S.Lott: estoy de acuerdo en que definitivamente hay una diferencia entre las DSL y la programación alfabetizada, pero creo que las DSL pueden ser una herramienta para lograr una verdadera programación alfabetizada en la que puede escribir lenguaje natural y hacer que exprese el algoritmo deseado. Para mí, mezclar lenguaje natural y código es una forma bastarda de alfabetización.
cdeszaq

"puede escribir lenguaje natural-ish y hacer que exprese el algoritmo deseado" es poco probable en el mejor de los casos. Hay antecedentes, justificación, prueba de corrección, aserciones de complejidad (big- O ) y mucha documentación de soporte no alogrítmica que no es parte de un esquema DSL. No estoy seguro de estar de acuerdo con el paralelo ahora que lo has aclarado.
S.Lott

1
"explicación de la lógica del programa". No es la lógica en sí. Pero una explicación. La lógica rara vez se explica por sí misma. Nunca contiene una prueba de corrección (eso es difícil y a veces imposible). Raramente contiene una justificación de la complejidad big-O. Y rara vez explica las alternativas que son un rendimiento más bajo o más memoria. Por lo tanto, sugeriría que DSL está muy por debajo de la "explicación".
S.Lott 01 de

-2

Creo que es un error pensar que LP es algún tipo de DSL. Debido a que LP es un diario (con diagramas, esquemas, fragmentos de pseudocódigo, es decir, fragmentos) del programa desarrollado, es arquitectura, etc. Es absolutamente análogo al cuaderno de papel, muchos de los desarrolladores los usan pero después de terminar el programa. deja tus cuadernos, papeles ...

Hace mucho tiempo, cada físico, astonómero, químico / alquimista, matemático tiene sus propios cuadernos, manuscritos con muchos esquemas, información necesaria, tablas, y sin ellos puede comprender o repetir su experiencia exitosa, sus resultados. Y siempre entre tales pueblos existe la caza de manuscritos / cuadernos.

¡Hoy muchos programadores escriben código, y a veces agregan comentarios! El programa Byt no es solo código: son pensamientos, ideas, imaginación, conceptos y, cuando el nuevo desarrollador hereda el código alienígena, rompe todas las ideas y conceptos con frecuencia, crea diferentes "lagunas" y "puertas traseras", espero que me entiendas :)

Por lo tanto, el requisito principal para LP (¡como herramienta!) También es permitir todo esto con una sintaxis simple, ligera y legible. Probé muchas herramientas de LP, pero hoy estoy desarrollando el propio - NanoLP ( http://code.google.com/p/nano-lp/ ), que tiene como objetivo cumplir con esta demanda.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.