Este post explica por qué me quedo con la programación funcional, utilizando una razón con la que un programador no funcional puede relacionarse.

La razón es bastante simple: los modismos de programación funcional son más duraderos y portátiles que los modismos de otros paradigmas de programación (como la programación de procedimientos o orientada a objetos). Para explicar por qué, primero tengo que definir lo que entiendo que significa "programación funcional" (que es ciertamente un término impreciso e impreciso).



Yo personalmente uso el término "programación funcional" para denotar un estilo de programación donde te restringes tanto como sea posible a las siguientes características del lenguaje:

  • Escalar, incluyendo:
    • Números
    • Cadenas
  • Tipos de datos algebraicos, incluidos:
    • Registros
    • Sindicatos etiquetados, incluyendo:
      • Bools
      • Valores opcionales
      • Enumeraciones
    • Recursión, incluyendo:
      • Listas
  • Funciones de primera clase

Tenga en cuenta cuidadosamente lo que está ausente de la lista. No mencionamos:

  • Clases / Objetos
  • Mutación
  • Modismos de programación estructurados (p. ej. / bucles)forwhile

Eso no quiere decir que esas características estén prohibidas de mi definición de programación funcional. Piense en la definición como más un "radar tecnológico" donde el primer conjunto de características caen en la categoría "Adoptar" y el último conjunto de características caen en la categoría "Hold".

Entonces, ¿qué distingue a las características "aprobadas" anteriores de las últimas características "desalentadas"? Las características de idioma aprobadas son "atemporales". Siempre vas a necesitar números, listas, cadenas, funciones, registros, etc. Ni siquiera son específicos de la programación: son anteriores a la programación y se originan en buenas matemáticas a la antigua. Si su idioma no admite una o más de esas características, tendrá dificultades para modelar algunos dominios problemáticos.

Sin embargo, una vez que te versos en modismos de programación funcional te das cuenta de que en realidad no necesitas mucho más allá de esas características:

  • ¿Manejo de errores? Utilice una unión etiquetada (por ejemplo. Either / Result)
  • ¿Bucles? Usar recursividad
  • ¿Inyección de dependencia? Utilice una función de orden superior

Cuando ves las cosas con esa luz comienzas a ver otros modismos de programación como un aderezo de ventana que va y viene; no es fundamental para la disciplina de la ingeniería de software.

Además, el uso de primitivas "atemporales" fomenta un estilo de programación que es más portátil que la mayoría. La mayoría de los modismos de programación funcional se pueden portar a cualquier idioma, con la notable excepción de la recursividad y los sindicatos etiquetados generalizados (que no todos los lenguajes admiten). Sin embargo, los programadores funcionales aprenden a traducir la recursividad y etiquetaron las uniones a expresiones equivalentes en otros idiomas (por ejemplo, bucles y el patrón de visitantes, respectivamente). Sin embargo, si intentas portar modismos orientados a objetos a un lenguaje no orientado a objetos, lo vas a pasar mal, también para migrar modismos imperativos a un lenguaje de programación funcional.

Esta es la razón por la que mi radar tecnológico marca la programación funcional como "Adopt" y marca otros paradigmas de programación como "Hold". 

Traducido al español referencia http://www.haskellforall.com/2020/10/why-i-prefer-functional-programming.html