¿Cuáles son algunos problemas con la programación estructurada?

Answer 1

Básicamente, la programación estructurada (en comparación con la programación funcional o incluso la programación orientada a objetos) no es muy buena para elaborar abstracciones. En esencia, los lenguajes estructurados son menos expresivos .

Esto significa que terminas escribiendo más código para hacer las mismas cosas y, al mismo tiempo, admites más errores.

Considere la diferencia entre usar un bucle y una función de orden superior como el mapa o el filtro. Con un bucle, una sola construcción ( for ejemplo,) realiza un montón de funciones diferentes. Puede usarlo para repetir una acción varias veces, iterar sobre una colección, iterar sobre parte de una colección, iterar sobre varias colecciones o cualquier combinación arbitraria de éstas.

En un lenguaje funcional, reemplazaría una construcción de bucle única con una biblioteca de “funciones de orden superior”, funciones que toman otras funciones como argumentos. Esto tiene algunas ventajas inmediatas:

• Ya que tienes diferentes nombres para diferentes patrones, lo que estás haciendo es claro de un vistazo. Con un bucle for, necesita leer el bucle real para averiguar exactamente qué está pasando. Con una función como el map , sabes simplemente por el nombre que todo lo que está haciendo es aplicar una función a cada valor en una lista.
• Las funciones de orden superior te dejan menos lugares para cometer un error. Si utiliza un estilo de bucle C para iterar sobre una colección, es muy fácil cometer ciertos errores, como los errores off-by-one. Con algo como map o fold , no se puede desordenar la indexación de esa manera. Esencialmente, el bucle expone demasiados detalles innecesarios que lo dejan con más errores potenciales, código más detallado y más pensamiento sin darle mucho a cambio.

  Por supuesto, probablemente sepa cómo escribir correctamente un bucle for para iterar sobre una sola lista, solo por experiencia. Pero los patrones más complejos, como comprimir dos listas o reducir todos los elementos de una lista con alguna operación, son menos comunes y mucho más fáciles de desordenar con un bucle for.

• Las funciones de orden superior no están integradas en el lenguaje. Esto le permite abstraer nuevos patrones que pueden ser importantes para su programa en particular. Por otro lado, las construcciones de lenguaje estructurado son, por su propia naturaleza, construcciones de lenguaje ; ¡No puede agregar un nuevo tipo de bucle a los lenguajes de programación estructurados!

  Este es un buen ejemplo del principio de diseñar lenguajes para crecer [1]. Los lenguajes estructurados realmente no pueden crecer, lo que pone un límite bastante bajo en cuanto a qué tan bien pueden adoptar a cualquier dominio dado.

Este es solo un ejemplo particular de cómo los lenguajes estructurados son menos expresivos. Es particularmente ilustrativo porque conduce a un código que es más difícil de leer , más difícil de escribir y más fácil de desordenar .

En la práctica, los lenguajes estructurados tienden a ser bastante malos tanto para abstraer sobre el flujo de control como para abstraer sobre los datos . Este es un inconveniente muy serio, especialmente para las personas que se preocupan por la calidad del código.

Por supuesto, si solo estás comparando un idioma con bucles a un idioma con goto, entonces es una historia diferente. Pero ese tipo de comparación es realmente miope, especialmente porque en estos días, el ensamblaje es básicamente lo único. ¡Y la gente no escribe la mayoría de los códigos directamente en ensamblaje por muy buenas razones!

[1]: Esta es una de mis charlas favoritas sobre diseño de lenguajes de programación, llamada “Growing a Language” por Guy Steele, quien estuvo detrás del diseño de un montón de lenguajes importantes, incluidos Scheme, Java y Fortran, así como los estándares para Un montón de otros lenguajes como JavaScript, C y Common Lisp.

Answer 2

La incapacidad de hacer co-rutinas, la incapacidad de saltar fuera de los bucles internos, la falta de respeto por las tablas de salto que se utilizan para analizar lenguajes regulares (como en lex), el descuento de la posibilidad de producir código a través de la evolución, en lugar de Diseño humano: olvídate del código de auto-modificación.

El artículo original “goto considerado como dañino” esencialmente envenenó la atmósfera para el diseño de idiomas para una generación y produjo lenguajes que ni siquiera ofrecían goto. Afortunadamente, C lo incluyó, de lo contrario, se habría quedado en el camino como Pascal (que no lo hizo; en realidad, de los comentarios me parece que sí, pero estaba demasiado estructurado de otras maneras).

La programación estructurada es una metodología política. Es útil usar bloques, cuando son útiles, y es útil escribir código spaghetti, y código de auto-modificación, cuando esta es la mejor manera de hacer las cosas. No es a menudo la mejor manera de hacer las cosas, necesita lidiar con la concurrencia, y la auto-modificación prohíbe la concurrencia, pero el dogma se usa en exceso para atacar a las personas. La programación es creativa, y las restricciones son lo opuesto a la creatividad. La programación estructurada es como la escala C-major, es una estructura que está hecha para romperse.