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?
literate-programmingetiqueta en StackOverflow. Hay más contenido allí, aunque todavía no mucho.Respuestas:
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.
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.
fuente
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.
fuente
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:
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):
fuente
turn left then rightopaint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/…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.
fuente