¿Qué es la programación funcional y por qué es tan especial?

4 minutos

Función

Cuando activas tu modo programador y picas la primera línea de código en el proyecto, aunque no lo sepas, vas a convertirte en arquitecto de software ya que tendrás que elegir la mejor forma de organizar tu código. Quedarte con uno de los 3 paradigmas predominantes, sabiendo que no habrá una vuelta a atrás, buscar aquella forma que mejor se adapte al tipo de proyecto y el equipo. Tus opciones son:

  • Programación estructurada, el código será ejecutado desde el principio del fichero al final sin seguir ningún tipo de desviación. Su mayor ventaja radica en su simplicidad y poco peso. Su peligrosidad es el código espagueti, archivos con centenares o miles de líneas donde solo unos pocos seres humanos son capaces de entrar a modificar y salir victoriosos.
  • Programación orientada a objetos (OOP o Object Oriented Programming), donde se encapsulan las variables y funciones en pequeños módulos capaces de clonarse y modificarse. Su punto fuerte es la capacidad de re-utilización y aislamiento para evitar problemas con otras funcionalidades. La parte negativa recae en la complejidad de crear buenos objetos y la depuración.
  • Programación funcional (FP o Functional programming), donde el código se reparete en sencillas funciones capaces de ser invocadas con variables u otras funciones. Su facilidad de uso por atomicidad (dividice y vencerás) logra un mantenimiento sólido y compatible con casi cualquier lenguaje. Además su inmutabilidad de variables evita gran parte de los problemas que si sufre la OOP. Desarrollaré más adelante las ventajas y desventajas pero adelanto que lo oscurece la poca información al respecto y el pequeño apoyo por parte de la comunidad.

La programación orientada a objetos esta sobrevalorada

Es tradición que en escuelas y universidades te den un primer acercamiento con un lenguaje imperativo, como puede ser C/C++, Java, Python o PHP. Sin una formación adecuada, los alumnos engordan sus ficheros haciendo que crezcan sin un fin aparente. Lo cual es natural ya que primero deben romper mano con los elementos esenciales como las variables, bucles, condicionales, arrays… Cuando llegan, o llegamos, a crear los primeros programas son imposibles de mantener. No recuerdan bien como funciona por no existir límites ergo modificar una sola línea provocaría una reacción en cadena imposible de predecir por la mala estructura. Por descontado realizar testing es desconocido e inútil por su parte. ¿Cómo se ayuda al alumno? ¿Qué hacen los profesores? Dar un paradigma capaz de separar todo el código en secciones y sea compatible con el lenguaje: programación orientada a objetos.

El paradigma no es gratuito, esta llena de conceptos propios: abstración, herencia, poliformismo, interfaces… Si eres capaz de esforzarte en asimilar todo esa locura de herramientas, ¿para que irte a otro paradigma? Es utilizado por casi cualquier lenguaje moderno, muchos Frameworks lo utilizan como base y hay muchos compañeros que pueden ayudarte. Puede que en este punto, y justo en este preciso momento, caigas en la trampa de pensar: “La programación orientada a objetos es la mejor, no necesito aprender otros paradigmas”. Justo aquí te puedes perder la magia de la programación funcional.

Si piensas de esa manera me gustaría que te hicieras las siguientes preguntas:

  • ¿Cuantos objetos fabricas, o utilizas, al día?
  • ¿Usas la herencia?
  • ¿Partir tu código en objetos hace más sencillo tu trabajo?
  • ¿Decides usar OOP o te impone el Framework que usas?

La realidad es que no usamos OOP, lo admiramos e intentamos alcanzarlo pero no es práctico en tu día a día. Después de todo cuando desarrollamos pequeños script no hay la necesidad de liarnos ha hacer un objeto con su constructor e interfaces, y cuando el proyecto es grande hacemos uso de algún Framework.

¿Eso significa que no debemos aprenderlo? Tienes que saber todas sus entrañas por muy profundas que que sean. Es útil, no hay paradigma inútil, y gran parte del software esta estructurado de esta manera. Javascript no deja de intentar acercarse creando abstraciones compatibles. Pero conocer algunos conceptos básicos de la programación funciona, no hace falta que aprendas Monadas, harán tu trabajo más limpio y sencillo.

¿Qué ventajas posee la programación funcional respecto a la programación orientada a objetos?

Pros

  • Inmutabilidad. Es el concepto de la programación funcional más difícil de entender, pero cuando lo pones en práctica llegas a preguntarte donde se ha escondido todo este tiempo. Las variables no deben cambiar. Si quieres modificar su contenido, simplemente creas otra. ¿Y que tiene eso de bueno? Tus datos son siempre sólidos, nada en tu código va a hacer que el código que trabaja con esa variable deje de funcionar; lo que se convierte en un software con apenas errores de un solo plumazo.
  • Facilidad de testing. Al estar todo repartidos en pequeñas funciones, que siempre te van a devolver algo, es realmente sencillo tensarlas para ver como se comportan en todos los casos.
  • Raro no encontrar un lenguaje compatible. Prácticamente cualquier lenguaje tiene funciones, retornos y ayudas para iterar.
  • Fácil de implementar en otro proyecto. Puedes tener PF en un proyecto OOP sin alterar la estructura.
  • Manipulación de listas. Olvídate de los bucles infinitos, solo vas a iterar arrays o listas.
  • Muy bien pagado. No es una característica del lenguaje, pero no quería terminar el artículo sin mencionar una realidad. Los programadores que usan lenguajes orientados a funciones son mejores pagados: Scala, Haskell, Clojure, Lisp… Y lo mismo ocurre con Javascript cuando usas un Framework de PF (ClojureScript y Elm).

Contras

  • Poca documentación. No hay muchos ejemplos y foros dedicados.
  • Lenguajes dificiles de entrar. Si te criaste con lenguajes OOP, será difícil cambiar tu forma de pensar; en cambio si es tu primer contacto te va a resultar más suave. Desde del punto de vista.
  • Rechazo por parte de compañeros y equipos. Estos lenguajes no suelen estar de moda, además que frecuentemente suelen estar injustamente infravalorados lo que desemboca no querer implementarlos en ningún proyecto.

Comentarios

{{ comments.length }} comentarios

Nuevo comentario

Nueva replica  {{ formatEllipsisAuthor(replyComment.author) }}

Acepto la política de Protección de Datos.

Escribe el primer comentario

Tal vez también te interese...