En los 煤ltimos d铆as, se han publicado varios art铆culos sobre Habr茅, cuyo lema general (especialmente en los comentarios) fue la confrontaci贸n entre personas contundentes y puntiagudas, adherentes del FP contra la OLP, aunque fueron llamados a no discutir. A veces se discuti贸 sobre Erlang, en relaci贸n con lo cual record茅 una breve publicaci贸n sobre un tema de Joe Armstrong, uno de los creadores de este lenguaje, escrita por 茅l a fines de 2018 en el foro de Elixir en respuesta a una pregunta sobre el paradigma del lenguaje. Creo que su comentario ser谩 interesante.
Joe Armstrong 12 de septiembre de 2018
Todas las cosas buenas de Elixir (y Erlang) est谩n relacionadas con la concurrencia, simplemente creando procesos y mensajes independientes. Y esta es exactamente la esencia de la programaci贸n orientada a objetos, como Alan Kay ha se帽alado repetidamente.
OOP est谩 totalmente dedicado a los objetos. Los objetos responden (o deber铆an responder) a los mensajes, y cuando quieres hacer algo, env铆as un mensaje al objeto, y la forma en que lo procesa es completamente irrelevante. Piense en los objetos como "cajas negras", y cuando quiera algo de ellos, simplemente env铆e mensajes y ellos le enviar谩n mensajes en respuesta.
La forma en que todo se organiza en el interior no importa si el c贸digo dentro del cuadro negro es funcional o imperativo, solo lo que debe hacer exactamente es importante.
Desafortunadamente, aunque el primer lenguaje exitoso orientado a objetos basado en este modelo (Smalltalk) operaba en los conceptos de "objeto" y "mensaje", este 煤ltimo en Smalltalk no eran mensajes reales, sino solo llamadas de funciones s铆ncronas enmascaradas. El mismo error se repiti贸 en C ++, luego en Java, y la idea principal de OOP degener贸 en un paradigma extra帽o para organizar el c贸digo en clases y m茅todos.
Erlang y Elixir facilitan la creaci贸n de millones de procesos aislados donde todo funciona enviando mensajes entre ellos. La arquitectura del sistema est谩 determinada por el nivel de paralelismo que desee, con su mapeo posterior a los procesos directamente.
El servidor web Elixir para 10,000 usuarios no es "un servidor web con 10,000 usuarios" (como es el caso de Apache o Jigsaw y similares), sino que es "10,000 servidores web por usuario" - acuerde, un radical desviaci贸n del modelo tradicional.
El hecho de que se haya utilizado un lenguaje funcional simple para describir el modelo de proceso Erlang / Elixir es casi un accidente. Todo comenz贸 con un sistema de programaci贸n l贸gica (Prolog), y cosas como el nodo C, por ejemplo, se pueden escribir en cualquier lenguaje. Lo realmente importante para Elixir (y cualquier otro lenguaje BEAM) es la capacidad de su m谩quina virtual para operar con una gran cantidad de procesos paralelos.
Durante mucho tiempo dije que "Erlang es el 煤nico lenguaje real orientado a objetos". Supongo que ahora puedo agregarle y Elixir.
Para OOP, las cosas b谩sicas son:
- aislamiento entre objetos (lo tenemos)
- enlace tard铆o (decidimos qu茅 hacer solo cuando el proceso recibe un mensaje)
- polimorfismo (todos los objetos pueden responder a un mensaje del mismo tipo, por ejemplo, "impr铆mate" y cualquier objeto puede saber c贸mo hacerlo)
Mucho menos importante:
- divisi贸n en clases y m茅todos
- sintaxis
- modelo de software (funcional o imperativo)
Despu茅s de dividir el sistema en una gran cantidad de peque帽os procesos que se comunican entre s铆, todo lo dem谩s se vuelve (relativamente) f谩cil: cada proceso debe ser bastante simple y poder hacer bastante, lo que simplifica enormemente la programaci贸n.
Lo que Erlang (y Elixir) aport贸 a la programaci贸n fue la idea de las comunicaciones (enlace - traductor aprox.). Inicialmente propuesto por Mike Williams, consiste en ampliar la posibilidad de manejo de errores, lo que permite que se realice fuera de los l铆mites de los procesos. Teniendo esto, obtuvimos todas las herramientas necesarias para construir 谩rboles de supervisi贸n, etc.
Los supervisores, gen_server's y todo ese jazz son solo bibliotecas que ocultan algunos detalles del usuario. Simple por dentro, escrito usando las mismas herramientas: procesos paralelos y las relaciones entre ellos.
Erlang no se desarroll贸 como un lenguaje de programaci贸n funcional, sino como una herramienta para crear sistemas tolerantes a fallos de larga duraci贸n.
Un elemento central de la tolerancia a fallas es el concepto de manejo remoto de errores. Si todo el sistema falla, el mal funcionamiento debe corregirse (compensarse) en otra m谩quina, ya que es imposible hacerlo localmente: la computadora local no funciona.
Esto significa que para programar sistemas tolerantes a fallas, necesitamos la distribuci贸n de (procesos) y mensajes para que sean herramientas f谩ciles de usar, y es por eso que, en principio, cualquier arquitectura tolerante a fallas terminar谩 pareci茅ndose a Erlang.
El objetivo de crear Erlang era simplificar la programaci贸n de sistemas tolerantes a fallas, cuyo efecto secundario era la facilidad de programar sistemas escalables.
La diferencia entre Erlang y Elixir y "todos los dem谩s" est谩 en los mecanismos para garantizar la concurrencia y la tolerancia a fallas, y esto no se trata de m贸nadas, sintaxis o "pureza" del FP.
Ahora la pregunta es: 驴desea procesar 10,000 usuarios en un hilo, utilizando devoluciones de llamada para emular la concurrencia, o a煤n desea crear 10,000 procesos paralelos, cada uno de los cuales es simple y no necesita devoluciones de llamada?
Cada proceso espera el mensaje que le interesa, luego realiza c谩lculos y se queda dormido en anticipaci贸n del siguiente.
Creo que el gran problema con la popularizaci贸n de Erlang / Elixir es que necesita explicar c贸mo muchos procesos paralelos ayudan a resolver su problema espec铆fico. Dado que inicialmente ning煤n otro lenguaje com煤n ten铆a como objetivo la programaci贸n paralela y no lo facilit贸 de manera significativa, la necesidad de hacerlo para las personas no se comprende y comprende completamente.
"Pero puedo hacer todo en devoluciones de llamada en un hilo", dir谩n. Y lo hacen, y es dolorosamente dif铆cil. Y preguntas "驴qu茅 sucede si la devoluci贸n de llamada entra en el bucle o produce una excepci贸n?", Y si no entienden la pregunta, entonces tienes que trabajar duro y explicar el problema. Pero si la pregunta es clara, d铆gales que hay un pa铆s distante en el que no se necesitan devoluciones de llamada para programar la concurrencia.
Parece que todo lo anterior se puede reducir a lo siguiente: no anuncie Elixir como un lenguaje de programaci贸n funcional, no lo es. Es un lenguaje de programaci贸n paralelo (CPL, lenguaje de programaci贸n concurrente).
No responda a argumentos como "mi lenguaje funcional es m谩s funcional que el suyo". Y ni siquiera se moleste en hablar de m贸nadas, cambie de tema inmediatamente.
"- 驴Qu茅 es una CPL?"
"- Sabes, esto es en lo que est谩 hecho WhatsApp ..."
Del traductor
En primer lugar, me gustar铆a expresar mi pesar por la repentina muerte de Joe Armstrong: muri贸 el 20 de abril de 2019. Es dif铆cil subestimar su contribuci贸n al desarrollo de la industria, as铆 como su talento como divulgador: libros, discursos y trabajo activo en las comunidades de Erlang y Elixir.
Enlaces utiles: