Vale, después de leer varios artículos que llevan a lo mismo, intentar meter la orientación a objetos en Erlang (y como estos otros ejemplos más que no citaré de momento).
Si pensamos lo que Alan Kay decía sobre la orientación a objetos, no se refería a tener un espacio en la memoria en la que albergar datos que pudiesen ser modificados a través de llamadas a funciones. Él definía de manera conceptual la instancia de un objeto, vivo, al que se le pasan mensajes para trabajar con esa información y retornar una respuesta. ¿No es más parecido a lo que se puede hacer con un gen_server, por ejemplo?
También hay gente que intenta hacer que los procesos de Erlang sean más eficientes que los de otros lenguajes y, sino lo son, Erlang no sirve... cuando, creo que está claro o sino es mejor repasarlo... que Erlang no destaca por la velocidad de sus procesos, sino por la versatilidad de poder crear millones de ellos e incluso a través de un cluster, de modo que se facilita la computación distribuida, no solo la concurrente.
Entonces, ¿cuál es realmente el fallo de que la gente piense en cosas como orientación a objetos o rendimiento de los procesos? ... que no han entendido el cambio de paradigma.
Programación Orientada a la Concurrencia
El paradigma que ofrece Erlang, y que está ofreciendo Go, y que se ofrece a través de Celluloid en Ruby, y otros muchos frameworks en otros diversos lenguajes, es lo que se conoce como Modelo Actor, o a mi me gusta llamar Programación orientada a la Concurrencia.
La programación orientada a la concurrencia se basa en los procesos, que son la unidad mínima de computación para concurrencia en este paradigma. Un proceso se define a través de un módulo y puede ser lanzado una o varias veces, dependiendo de la cantidad de procesos que puedan existir en ejecución para un programa específico.
El proceso es en este paradigma lo que el objeto en el paradigma de la orientación a objetos, teniendo un espacio de memoria (heap) en el que almacena datos privados y que él solo puede manipular, y la posibilidad de recibir mensajes para realizar acciones concretas retornando, o no, un valor. En este sentido, agregamos la posibilidad, porque de concurrencia hablamos, de llamadas síncronas o asíncronas.
Como cada proceso, es una entidad de memoria que almacena datos y que responde a la ejecución de código, se puede especificar con un diagrama de clases UML este diseño, teniendo presente la cardinalidad para la existencia de 1 a N posibles instancias de procesos.
Además, a través de los comportamientos, Erlang nos permite crear entidades avanzadas como supervisores, máquinas de estados y generadores de eventos. Estas entidades facilitan enormemente el trabajo de programación de entidades que antes, en el paradigma de objetos, eran impensables.
Diseñar una web en la que se emplea un controlador a través de una máquina de estados para hacer un sistema statefull que mantiene la sesión en memoria sin necesidad de serializar/deserializar información. Además de, en caso de necesitar enviar información a un log o una inserción demorada (sea cual sea la base de datos), es algo que tan solo se puede hacer a través de programación paralela.
Por otro lado, la optimización. El cómputo del coste algorítmico queda totalmente desfasado, realmente. En un servidor de cuádruple núcleo con dos procesadores (16 en total), un algoritmo que se ejecuta de forma distribuida, además, en dos instancias una en cada servidor como el mencionado, tiene la posibilidad de ejecutarse 32 veces más rápido que un programa escrito de forma secuencial o empleando hilos (que normalmente no emplean varias CPUs).
¿Ahora sí?
En esencia. Esto es como cuando salió GTK para PHP, si PHP no está diseñado para estar más de 15 minutos en ejecución (porque se suele bloquear y tiene siempre algún que otro leak de memoria), ¿por qué intentamos introducir orientación a objetos en un lenguaje funcional cuando la metodología más idónea es la orientación a la concurrencia (o el modelo actor)? Acepto comentarios que lo aclaren (si es que esto es posible :-D ).
