Programación funcional vs programación orientada a objetos [cerrado]

Hasta ahora he estado expuesto principalmente a la programación OO y espero aprender un lenguaje funcional. Mis preguntas son:

• ¿Cuándo elige la programación funcional en lugar de orientada a objetos?
• ¿Cuáles son las definiciones típicas de problemas donde la programación funcional es una mejor opción?

¿Cuándo elige la programación funcional en lugar de orientada a objetos?

Cuando anticipa un tipo diferente de evolución del software:

• Los lenguajes orientados a objetos son buenos cuando tiene un conjunto fijo de operaciones sobre cosas y, a medida que su código evoluciona, agrega principalmente cosas nuevas. Esto se puede lograr agregando nuevas clases que implementen métodos existentes, y las clases existentes se dejan solas.

• Los lenguajes funcionales son buenos cuando tiene un conjunto fijo de cosas y, a medida que su código evoluciona, agrega principalmente nuevas operaciones en cosas existentes. Esto se puede lograr agregando nuevas funciones que computan con los tipos de datos existentes, y las funciones existentes se dejan solas.

Cuando la evolución va por el camino equivocado, tienes problemas:

• Agregar una nueva operación a un programa orientado a objetos puede requerir editar muchas definiciones de clase para agregar un nuevo método.

• Agregar un nuevo tipo de cosas a un programa funcional puede requerir editar muchas definiciones de funciones para agregar un nuevo caso.

Este problema se conoce desde hace muchos años; en 1998, Phil Wadler lo denominó el "problema de expresión" . Aunque algunos investigadores piensan que el problema de la expresión puede abordarse con características del lenguaje como los mixins, una solución ampliamente aceptada aún no ha llegado a la corriente principal.

¿Cuáles son las definiciones típicas de problemas donde la programación funcional es una mejor opción?

Los lenguajes funcionales sobresalen en la manipulación de datos simbólicos en forma de árbol. Un ejemplo favorito son los compiladores, donde los lenguajes de origen e intermedios cambian raramente (principalmente las mismas cosas ), pero los escritores de compiladores siempre agregan nuevas traducciones y mejoras u optimizaciones de código (nuevas operaciones en las cosas). La compilación y la traducción en general son "aplicaciones geniales" para lenguajes funcionales.

No necesariamente tiene que elegir entre los dos paradigmas. Puede escribir software con una arquitectura OO utilizando muchos conceptos funcionales. FP y OOP son de naturaleza ortogonal .

Tomemos por ejemplo C #. Se podría decir que es principalmente OOP, pero hay muchos conceptos y construcciones de FP. Si considera Linq , las construcciones más importantes que permiten que Linq exista son de naturaleza funcional: expresiones lambda .

Otro ejemplo, F #. Se podría decir que es principalmente FP, pero hay muchos conceptos y construcciones de OOP disponibles. Puede definir clases, clases abstractas, interfaces, lidiar con la herencia. Incluso puede usar la mutabilidad cuando aclara su código o cuando aumenta drásticamente el rendimiento.

Muchos lenguajes modernos son multi-paradigmáticos.

Lecturas recomendadas

Como estoy en el mismo barco (antecedentes de OOP, aprendiendo FP), te sugiero algunas lecturas que realmente aprecio:

• Programación funcional para el desarrollo diario de .NET , por Jeremy Miller. Un gran artículo (aunque mal formateado) que muestra muchas técnicas y ejemplos prácticos del mundo real de FP en C #.

• Programación funcional del mundo real , por Tomas Petricek. Un gran libro que trata principalmente con conceptos de PF, tratando de explicar qué son, cuándo deben usarse. Hay muchos ejemplos en F # y C #. Además, el blog de Petricek es una gran fuente de información.

La programación orientada a objetos ofrece:

1. Encapsulación, a
   • controlar la mutación del estado interno
   • limitar el acoplamiento a la representación interna
2. Subtipado, permitiendo:
   • sustitución de tipos compatibles (polimorfismo)
   • Un medio crudo de compartir la implementación entre clases (herencia de implementación)

La programación funcional, en Haskell o incluso en Scala, puede permitir la sustitución a través de un mecanismo más general de clases de tipos. El estado interno mutable está desalentado o prohibido. La encapsulación de la representación interna también se puede lograr. Ver Haskell vs OOP para una buena comparación.

La afirmación de Norman de que "agregar un nuevo tipo de cosas a un programa funcional puede requerir editar muchas definiciones de funciones para agregar un nuevo caso". depende de qué tan bien el código funcional ha empleado clases de tipos. Si la coincidencia de patrones en un tipo de datos abstractos en particular se extiende a través de una base de código, de hecho sufrirá este problema, pero quizás sea un mal diseño para comenzar.

EDITADO Se eliminó la referencia a las conversiones implícitas al analizar las clases de tipos. En Scala, las clases de tipos están codificadas con parámetros implícitos, no conversiones, aunque las conversiones implícitas son otro medio para lograr la sustitución de tipos compatibles.

1. Si se encuentra en un entorno muy concurrente, entonces la programación funcional pura es útil. La falta de estado mutable hace que la concurrencia sea casi trivial. Ver Erlang

2. En un lenguaje multiparadigm, es posible que desee modelar algunas cosas funcionalmente si la existencia de un estado mutable es un detalle de implementación y, por lo tanto, FP es un buen modelo para el dominio del problema. Por ejemplo, vea la lista de comprensiones en Python o std.range en el lenguaje de programación D. Estos están inspirados en la programación funcional.