¿Cuáles son las desventajas de la programación procesal?

Si la programación procesal fuera la única forma de programar, no tendría ventajas ni desventajas. No hay otra forma de hacerlo; No tienes elección.

Sin embargo, hay muchos, muchos paradigmas de programación. Y muchas, muchas formas diferentes de compararlos.

La programación de procedimientos es básicamente una colección abierta de procedimientos y funciones que consisten en secuencias de enunciados de diversos tipos (como selección e iteración ). En el mejor de los casos, la única herramienta organizativa que tiene para administrar su base de código es el concepto de módulo (en C, “módulos” se implementarían como archivos de código y archivos de encabezado). Esto es aceptable para proyectos de tamaño modesto.

Sin embargo, para aplicaciones verdaderamente complejas, necesita una forma más sofisticada de modelar el problema (y, por lo tanto, administrar su código). El más utilizado hoy en día es la programación orientada a objetos (o POO). Otro método que está ganando popularidad es la programación funcional (o FP).

En este contexto, la desventaja de la programación de procedimientos sería la falta de una estructura cognitiva para comprender las relaciones entre todos sus procedimientos y funciones y sus datos. Todo se vería como una masa enorme y amorfa. Los “módulos” ayudarían, pero pueden no ser suficientes.

Personalmente, me gusta pensar en términos de “objetos” que poseen atributos y comportamiento. Hace que sea más fácil ver el panorama general de una aplicación. Ver ¿La programación funcional está superando a la industria de TI?

La principal desventaja de la programación de procedimientos es que no es tan rápido de ejecutar en comparación con el código escrito en un lenguaje de nivel inferior. Para aplicaciones que requieren mucha potencia de procesamiento, esto puede limitar la efectividad de la programación de procedimientos.

Otra desventaja de la programación de procedimientos es que tiene dificultades para manejar situaciones en las que una serie de acciones posibles pueden conducir al resultado deseado. Los programas de inteligencia artificial, por ejemplo, pueden no ser adecuados para la programación de procedimientos.

Los programadores también necesitan especializarse en un lenguaje de programación procesal específico, porque cada lenguaje es adecuado para un cierto tipo de aplicación y es difícil aprenderlos todos.

La programación de procedimientos le permite al programador escribir un conjunto de instrucciones para que la computadora las lleve a cabo en un cierto orden. Es uno de los tipos de programación más populares y se utiliza para una amplia gama de aplicaciones. Ejemplos de lenguajes de programación procesal incluyen C y Pascal.

A pesar de las desventajas, hay una serie de ventajas de la programación de procedimientos. Para las aplicaciones de programación general, los lenguajes de procedimiento son mucho más flexibles que otras alternativas, ya que el código fuente puede ejecutarse en diferentes tipos de procesadores. También hay muchos libros y otros materiales de aprendizaje disponibles para lenguajes de programación de procedimientos.

Creo que tu pregunta está mal planteada. ¿En relación con qué programación procesal está en desventaja? A OOP? ¿A la programación funcional? La única respuesta que me viene a la mente, ya que todo en informática es: depende . Un lenguaje de programación de procedimientos como C es excelente para escribir controladores de kernel, por ejemplo, pero no lo son cuando la complejidad del software supera un cierto umbral que se encuentra entre el mantenimiento del código y la solidez / facilidad de desarrollo del código. Pero si su jefe quiere que escriba ese software CRM basado en la nube en C, entonces su mejor opción es arremangarse y hacer ese trabajo en C (por lo que podemos decir que, en este caso específico, esto es una desventaja para programación de procedimientos).

No se adapta bien al problema o sistema que necesita resolver o representar en el código: aumenta el tamaño, la complejidad y el tamaño del equipo.

Los enfoques alternativos intentan superar esto.

A fines de la década de 1950, la programación modular basada en procedimientos y subrutinas se había vuelto problemática. Era difícil tener grandes equipos de programadores trabajando en partes del código al mismo tiempo, y era difícil crear grandes programas bien estructurados.

La respuesta en la década de 1960 fue dividir un problema en pedazos, luego subcomponentes, luego subrutinas mediante descomposición funcional . Esto permitió que se entendieran los grandes problemas y que diferentes equipos los trabajaran al mismo tiempo. Esto se conoce como programación estructurada .

Este enfoque ha dado como resultado un software de calidad a lo largo de los años, pero tiene limitaciones dolorosas. Uno de los grandes es que a medida que uno trabaja en un problema y descubre sus requisitos, la descomposición utilizada debe modificarse, a menudo de arriba hacia abajo.

De la comprensión de un enfoque orientado a objetos y alternativas