Después de 20 años programando en diversas metodologías y lenguajes, me doy cuenta de que muchos de los lenguajes que he aprendido y muchas de las metodologías en las que me he visto sumergido han sido protagonizadas por una moda.
Una forma de hacer las cosas típica de una época y que nadie discutía. Todos querían hacer su trabajo y si la forma de hacerlo, aunque algo extraña, era enumerar las líneas de 10 en 10 con sentencias que permitían saltar entre ellas era algo racional y lógico. Si la moda imponía que se hacía mejor todo en bloques de código que ofrecían verbos de acción y módulos, subrutinas, funciones, rutinas o procedimientos para albergar el código, pues igualmente alabamos la mejora y seguimos desarrollando.
En un momento dado, ya no solo la forma de codificar cambió, organizando el código entorno a los datos preferentemente y de un punto de vista mejor que orientándonos a los verbos o al orden de las líneas y ahí hemos permanecido, todo se plantea bastante lógico. Todos programamos y diseñamos el software con las herramientas que dilucidan cada nueva ventaja para el software, desde diagramas de flujo, organigramas, diagramas de Jackson, Entidad-Relación... hasta llegar a UML, FMC y otros que surgen cada día.
Pero, ¿quién ha dicho que el avance queda ahí?
La Orientación a Objetos distrae
Cuando se impuso la orientación a objetos hubo muchos detractores que veían con malos ojos el hecho de crear objetos cuando la programación estructurada les daba mayor libertad para organizar su código. La programación estructurada se enfocaba en una metodología concreta que funcionaba, que ayudaba a generar programas útiles y los que programaban con ella la entendían y no concebían que se pudiese programar de otra forma. Pero muchos otros habían comenzado a emplear estructuras de datos y punteros a funciones como pseudo-objetos y vieron en la programación orientada a objetos una solución y un enfoque mejorado de algo que veían que faltaba en su forma de hacer software.
De siempre en todos los campos ha habido detractores y simpatizantes. En este caso, hay que decir que cada uno de ellos tenía razón. La orientación a objetos no soluciona el 100% de los problemas de la programación y en su mayor medida, la solución que propone no es óptima. Un ejemplo de la curva de aprendizaje:
Por lo que los detractores de la programación orientada a objetos, como vemos, tenían algo de razón. No toda, pero si algo :-)
El enfoque funcional
En la Universidad de Washington, a través del curso de lenguajes de programación que imparten en la plataforma de Coursera, el profesor Dan Grossman sostiene que El énfasis en la programación funcional es esencial para aprender como escribir programas robustos, reutilizables, compuestos y elegantes en cualquier lenguaje.
En esa misma línea, la Carnegie Mellon University ha decidido eliminar de su temario de asignaturas para la carrera de informática la orientación a objetos y creado una nueva asignatura de Programación Funcional.
¿Qué lleva estas dos universidades y otras más que se suman a este movimiento a cambiar o agregar y enfatizar su educación en torno a la programación funcional? Según la definición sobre la programación funcional en la wikipedia, es un paradigma de programación declarativa basado en la utilización de funciones aritméticas que no maneja datos mutables o de estado. Enfatiza la aplicación de funciones, en contraste con el estilo de programación imperativa, que enfatiza los cambios de estado. La programación funcional tiene sus raíces en el cálculo lambda, un sistema formal desarrollado en los 1930s para investigar la definición de función, la aplicación de las funciones y la recursión. Muchos lenguajes de programación funcionales pueden ser vistos como elaboraciones del cálculo lambda..
Esto quiere decir que la elaboración de algoritmos de base científica es representada de forma más precisa a través de programación funcional que a través de la programación imperativa. Viendo el típico ejemplo del cálculo del factorial se entiende bastante bien esto:
El código en C, por ejemplo, sería así:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
int n, resultado;
if (argc == 2) {
n = atoi(argv[1]);
resultado = n;
while (--n>=1) {
resultado *= n;
}
printf("%s! = %d\n", argv[1], resultado);
} else {
printf("Usage: %s <n>\n", argv[]);
}
return ;
}El mismo código en un lenguaje funcional sería un poco más aproximado a la definición matemática al emplear recursividad y un estado no mutable:
#!/usr/bin/env escript
fact(1) -> 1;
fact(N) -> N * fact(N-1).
main([]) ->
io:format("Usage: ./fact.erl <n>~n");
main([Str]) ->
N = list_to_integer(Str),
io:format("~p! = ~p~n", [N, fact(N)]),
.El código funcional es declarativo de por sí. Indica mejor qué es lo que hace y no tanto el cómo lo hace, como pasa con lenguajes imperativos como C. Intentar realizar códigos como estos orientados a objetos solo agregaría ruido, ya que el código es tan simple de por sí que no requiere de una estructura orientada a objetos.
Conclusiones
La orientación a objetos es un paradigma muy válido para la construcción de sistemas de información como se ha demostrado en multitud de ocasiones. Pero cierto es que muchas de esas construcciones sería impensable realizarlas sin la ayuda de un IDE muy enfocado al lenguaje de programación orientado a objetos que se esté empleando.
La programación funcional viene para simplificar estas grandes construcciones y agregar una lógica implícita en el código que ayude al programador no solo a escribir buen código, sino a comprenderlo mejor cuando lo lea, ya sea programado por él u otra persona.
