software programacion patrones funcional ejemplos diseño comportamiento arquitectura oop design-patterns functional-programming gang-of-four

oop - programacion - ¿La programación funcional reemplaza los patrones de diseño de GoF?



patrones de diseño programacion (24)

Desde que comencé a aprender F # y OCaml el año pasado, he leído una gran cantidad de artículos que insisten en que los patrones de diseño (especialmente en Java) son soluciones para las funciones que faltan en los idiomas imprescindibles. Un artículo que encontré hace una afirmación bastante fuerte :

La mayoría de las personas que he conocido han leído el libro Design Patterns de la banda de los cuatro. Cualquier programador que se respete a sí mismo le dirá que el libro es independiente del lenguaje y que los patrones se aplican a la ingeniería de software en general, independientemente del idioma que utilice. Este es un reclamo noble. Lamentablemente está muy alejado de la verdad.

Los lenguajes funcionales son extremadamente expresivos. En un lenguaje funcional, uno no necesita patrones de diseño porque es probable que el lenguaje tenga un nivel tan alto que termine programando conceptos que eliminen todos los patrones de diseño.

Las características principales de la programación funcional incluyen funciones como valores de primera clase, valores reales, valores inmutables, etc. No me parece obvio que los patrones de diseño OO se aproximen a cualquiera de esas características.

Además, en los lenguajes funcionales que admiten OOP (como F # y OCaml), me parece obvio que los programadores que usan estos lenguajes usarían los mismos patrones de diseño disponibles para todos los demás lenguajes OOP. De hecho, en este momento uso F # y OCaml todos los días, y no hay diferencias notables entre los patrones que utilizo en estos idiomas en comparación con los patrones que uso cuando escribo en Java.

¿Hay algo de cierto en la afirmación de que la programación funcional elimina la necesidad de patrones de diseño OOP? Si es así, ¿podría publicar o enlazar a un ejemplo de un patrón de diseño de POO típico y su equivalente funcional?

¿Hay algo de cierto en la afirmación de que la programación funcional elimina la necesidad de patrones de diseño OOP?

La programación funcional no es lo mismo que la programación orientada a objetos. Los patrones de diseño orientados a objetos no se aplican a la programación funcional. En cambio, tienes patrones de diseño de programación funcional.

Para la programación funcional, no leerá los libros de patrones de diseño OO, leerá otros libros sobre patrones de diseño de PF.

lenguaje agnóstico

No totalmente. Solo lenguaje agnóstico con respecto a los idiomas OO. Los patrones de diseño no se aplican en absoluto a los lenguajes de procedimiento. Apenas tienen sentido en un contexto de diseño de base de datos relacional. No se aplican al diseñar una hoja de cálculo.

¿Un patrón de diseño típico de OOP y su equivalente funcional?

Lo anterior no debería existir. Eso es como pedir una pieza de código de procedimiento reescrito como código OO. Ummm ... Si traduzco el Fortran (o C) original a Java, no he hecho nada más que traducirlo. Si lo reescribo totalmente en un paradigma OO, ya no se parecerá al Fortran o C original, será irreconocible.

No hay una asignación simple de OO Design a Functional Design. Son formas muy diferentes de ver el problema.

La programación funcional (como todos los estilos de programación) tiene patrones de diseño. Las bases de datos relacionales tienen patrones de diseño, OO tiene patrones de diseño, la programación de procedimientos tiene patrones de diseño. Todo tiene patrones de diseño, incluso la arquitectura de los edificios.

Los patrones de diseño, como concepto, son una forma atemporal de construir, independientemente de la tecnología o el dominio del problema. Sin embargo, los patrones de diseño específicos se aplican a dominios y tecnologías de problemas específicos.

Todos los que piensen en lo que están haciendo descubrirán patrones de diseño.

Como dijo la respuesta aceptada, OOP y FP tienen sus patrones específicos.

Sin embargo, hay algunos patrones que son tan comunes que deberían tener todas las plataformas de programación que se me ocurran. Aquí hay una lista (incompleta):

  • Adaptador. Difícilmente puedo pensar en una plataforma de programación útil que sea tan completa (y autocumplida) que no necesite hablar con el mundo. Si va a hacerlo, definitivamente se necesita un adaptador.

  • Fachada. Cualquier plataforma de programación que pueda manejar un código fuente grande debería poder modularizarse. Si tuviera que crear un módulo para otras partes del programa, querrá ocultar las partes "sucias" del código y darle una interfaz agradable.

  • Interprete. En general, cualquier programa está haciendo dos cosas: analizar la entrada y la salida de impresión. Las entradas del mouse deben analizarse y los widgets de ventana deben imprimirse. Por lo tanto, tener un intérprete incorporado le da al programa un poder adicional para personalizar las cosas.

También, noté que en un lenguaje típico de PF, Haskell, hay algo similar a los patrones de GoF, pero con nombres diferentes. En mi opinión, esto sugiere que estuvieron allí porque hay algunos problemas comunes que deben resolverse en los idiomas de FP y OOP.

  • Mónada transformadora y decoradora. El primero utilizado para agregar habilidad adicional a una mónada existente, el último agrega habilidad adicional a un objeto existente.

Como han dicho otros, hay patrones específicos de programación funcional. Creo que el problema de deshacerse de los patrones de diseño no es tanto una cuestión de cambiar a funcional, sino una cuestión de lenguaje .

Eche un vistazo a cómo Scala elimina el "patrón de singleton": simplemente declara un objeto en lugar de una clase. Otra característica, la coincidencia de patrones, ayuda a evitar la confusión del patrón del visitante. Vea la comparación aquí: http://andymaleh.blogspot.com/2008/04/scalas-pattern-matching-visitor-pattern.html

Y Scala, como F #, es una fusión de OO-funcional. No sé sobre F # pero probablemente tiene este tipo de características.

Los cierres están presentes en el lenguaje funcional, pero no necesitan estar restringidos a ellos. Ayudan con el patrón del delegador.

Una observación más. Esta pieza de código implementa un patrón: es un clásico y es tan elemental que generalmente no lo consideramos como un "patrón", pero seguro que es:

for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }

Los lenguajes imperativos como Java y C # han adoptado lo que es esencialmente una construcción funcional para hacer frente a esto: "foreach".

Creo que cada paradigma tiene un propósito diferente y, como tal, no se puede comparar de esta manera.

No he oído que los patrones de diseño de GoF sean aplicables a todos los idiomas. He oído que son aplicables a todos los idiomas OOP . Si utiliza la programación funcional, el dominio de los problemas que resuelva es diferente de los lenguajes OO.

No usaría un lenguaje funcional para escribir una interfaz de usuario, pero uno de los lenguajes OO como C # o Java facilitaría este trabajo. Si escribiera un lenguaje funcional, no consideraría el uso de patrones de diseño OO.

Creo que solo dos patrones de diseño de GoF están diseñados para introducir la lógica de programación funcional en el lenguaje OO natural. Pienso en estrategia y comando. Algunos de los otros patrones de diseño de GoF pueden modificarse mediante la programación funcional para simplificar el diseño y mantener el propósito.

Cuando intente ver esto en el nivel de "patrones de diseño" (en general) y "PF versus POO", las respuestas que encontrará serán turbias, en el mejor de los casos.

Sin embargo, vaya un nivel más profundo en ambos ejes y tenga en cuenta los patrones de diseño específicos y las características específicas del lenguaje, y las cosas se aclararán.

Así, por ejemplo, algunos patrones específicos, como Visitante , Estrategia , Comando y Observador, definitivamente cambian o desaparecen cuando se usa un idioma con tipos de datos algebraicos y coincidencia de patrones , cierres , funciones de primera clase , etc. Algunos otros patrones del libro de GoF todavía "Quédate alrededor", sin embargo.

En general, diría que, con el tiempo, los patrones específicos se están eliminando con las nuevas características del lenguaje (o simplemente el aumento de popularidad). Este es el curso natural del diseño del lenguaje; a medida que los idiomas se vuelven más de alto nivel, las abstracciones que antes solo podían mencionarse en un libro usando ejemplos ahora se convierten en aplicaciones de una biblioteca o característica de idioma en particular.

(Aparte: aquí hay un blog reciente que escribí, que tiene otros enlaces para más discusiones sobre FP y patrones de diseño).

E incluso las soluciones OO Design Pattern son específicas del idioma. Los patrones de diseño son soluciones a problemas comunes que su lenguaje de programación no le resuelve. En Java, el patrón Singleton resuelve el problema de uno-de-algo (simplificado). En Scala, tienes una construcción de nivel superior llamada Objeto además de Clase. Está perezosamente instanciado y solo hay uno. No tienes que usar el patrón Singleton para obtener un Singleton. Es parte del lenguaje.

El libro de GOF se vincula explícitamente con OOP: el título es Patrones de diseño: elementos de software orientado a objetos reutilizables (énfasis mío).

En el nuevo libro de 2013 llamado "Patrones de programación funcional- en Scala y Clojure", el autor Michael.B. Linn hace un buen trabajo comparando y proporcionando reemplazos en muchos casos para los patrones GoF y también analiza los patrones funcionales más nuevos como ''recursión de la cola'', ''memoización'', ''secuencia perezosa'', etc.

Este libro está disponible en Amazon. Lo encontré muy informativo y alentador cuando provenía de un entorno de OO de un par de décadas.

En la Programación Funcional, los patrones de diseño tienen un significado diferente, de hecho, la mayoría de los patrones de diseño de POO son innecesarios en la Programación Funcional debido al mayor nivel de abstracción y HOF utilizados como bloques de construcción.

El principio de un HOF significa que las funciones se pueden pasar como argumentos a otras funciones. Y las funciones pueden devolver valores.

Esencialmente, sí !

  • Cuando un patrón elude las características faltantes (funciones de alto orden, manejo de flujo ...) que facilitan la composition .
  • La necesidad de volver a escribir la implementación de los patrones una y otra vez puede verse como un olor de lenguaje .

Además, esta página (AreDesignPatternsMissingLanguageFeatures) proporciona una tabla de traducción de "patrones / características" y algunas buenas discusiones, si está dispuesto a excavar.

La POO y la PF tienen objetivos diferentes, la POO tiene como objetivo encapsular las complejidades / partes móviles de los componentes del software y la PF tiene como objetivo minimizar la complejidad y las dependencias de los componentes del software; sin embargo, estos 2 paradigmas no son necesariamente contradictorios al 100% y pueden aplicarse juntos para obtener el beneficio de ambos mundos. Incluso con un lenguaje que no admite de forma nativa la programación funcional como C #, puede escribir código funcional si entiende los principios de PF, de igual manera podría aplicar los principios de OOP utilizando F # si entiende los principios, patrones y mejores prácticas de POO. Usted tomaría la decisión correcta en función de la situación y el problema que intenta resolver, independientemente del lenguaje de programación que utilice.

La presentación de Norvig alude a un análisis que hicieron de todos los patrones de GoF, y dicen que 16 de los 23 patrones tenían implementaciones más simples en lenguajes funcionales, o simplemente eran parte del lenguaje. Entonces, presumiblemente, al menos siete de ellos fueron a) igualmente complicados o b) no estaban presentes en el idioma. Desafortunadamente para nosotros, no están enumerados!

Creo que está claro que la mayoría de los patrones "creacionales" o "estructurales" en GoF no son más que trucos para lograr que los sistemas de tipos primitivos en Java o C ++ hagan lo que usted quiere. Pero el resto es digno de consideración, sin importar en qué idioma programes.

Uno podría ser un prototipo; Si bien es una noción fundamental de JavaScript, debe implementarse desde cero en otros idiomas.

Uno de mis patrones favoritos es el patrón Objeto nulo: representa la ausencia de algo como un objeto que hace un tipo apropiado de nada. Esto puede ser más fácil de modelar en un lenguaje funcional. Sin embargo, el verdadero logro es el cambio de perspectiva.

La programación funcional no reemplaza los patrones de diseño. Los patrones de diseño no pueden ser reemplazados.

Los patrones simplemente existen; emergieron con el tiempo. El libro de GoF formalizó algunos de ellos. Si surgen nuevos patrones a medida que los desarrolladores usan lenguajes de programación funcionales, eso es algo emocionante, y quizás también haya libros escritos sobre ellos.

La publicación del blog que usted citó exagera un poco su reclamo. FP no elimina la necesidad de patrones de diseño. El término "patrones de diseño" simplemente no se usa ampliamente para describir lo mismo en los idiomas de PF. Pero ellos existen. Los lenguajes funcionales tienen muchas reglas de mejores prácticas de la forma "cuando encuentre el problema X, use un código que se parece a Y", que es básicamente lo que es un patrón de diseño.

Sin embargo, es correcto que la mayoría de los patrones de diseño de OOP son bastante irrelevantes en los lenguajes funcionales.

No creo que deba ser particularmente controvertido decir que los patrones de diseño en general solo existen para corregir las deficiencias del lenguaje. Y si otro idioma puede resolver el mismo problema de manera trivial, ese otro idioma no necesitará un patrón de diseño para él. Es posible que los usuarios de ese idioma ni siquiera sepan que el problema existe , porque, bueno, no es un problema en ese idioma.

Esto es lo que dice Gang of Four sobre este tema:

La elección del lenguaje de programación es importante porque influye en el punto de vista de uno. Nuestros patrones asumen características de lenguaje de nivel Smalltalk / C ++, y esa elección determina qué se puede y qué no se puede implementar fácilmente. Si asumiéramos lenguajes de procedimiento, podríamos haber incluido patrones de diseño llamados "Herencia", "Encapsulación" y "Polimorfismo". De manera similar, algunos de nuestros patrones son compatibles directamente con los lenguajes menos comunes orientados a objetos. CLOS tiene varios métodos, por ejemplo, que disminuyen la necesidad de un patrón como el de Visitante. De hecho, existen diferencias suficientes entre Smalltalk y C ++ para que algunos patrones puedan expresarse más fácilmente en un idioma que en el otro. (Ver Iterator por ejemplo.)

(Lo anterior es una cita del libro Introducción a los patrones de diseño, página 4, párrafo 3)

Las características principales de la programación funcional incluyen funciones como valores de primera clase, valores reales, valores inmutables, etc. No me parece obvio que los patrones de diseño OO se aproximen a cualquiera de esas características.

¿Cuál es el patrón de comando, si no una aproximación de funciones de primera clase? :) En un lenguaje de PF, simplemente pasaría una función como argumento a otra función. En un lenguaje OOP, tiene que envolver la función en una clase, que puede instanciar y luego pasar ese objeto a la otra función. El efecto es el mismo, pero en OOP se denomina patrón de diseño y requiere mucho más código. ¿Y cuál es el patrón abstracto de fábrica, si no es curry? Pase los parámetros a una función poco a poco, para configurar qué tipo de valor escupe cuando finalmente lo llama.

Entonces, sí, varios patrones de diseño de GoF se vuelven redundantes en lenguajes FP, porque existen alternativas más poderosas y fáciles de usar.

Pero, por supuesto, todavía hay patrones de diseño que no están resueltos por los lenguajes de FP. ¿Cuál es el equivalente de FP de un singleton? (Ignorar por un momento que los singletons son generalmente un patrón terrible de usar)

Y funciona en ambos sentidos también. Como dije, la FP también tiene sus patrones de diseño, la gente no suele pensar en ellos como tales.

Pero puede que hayas encontrado mónadas. ¿Qué son, si no un patrón de diseño para "tratar con el estado global"? Ese es un problema tan simple en lenguajes OOP que no existe un patrón de diseño equivalente allí.

No necesitamos un patrón de diseño para "incrementar una variable estática" o "leer desde ese socket", porque es lo que haces .

En los lenguajes funcionales (puros), los efectos secundarios y el estado mutable son imposibles, a menos que trabaje con el "patrón de diseño" de la mónada, o cualquiera de los otros métodos para permitir lo mismo.

Además, en los lenguajes funcionales que admiten OOP (como F # y OCaml), me parece obvio que los programadores que usan estos lenguajes usarían los mismos patrones de diseño disponibles para todos los demás lenguajes OOP. De hecho, ahora mismo uso F # y OCaml todos los días, y no hay diferencias notables entre los patrones que utilizo en estos lenguajes y los patrones que uso cuando escribo en Java.

Tal vez porque todavía estás pensando imperativamente? Una gran cantidad de personas, después de lidiar con los lenguajes imperativos durante toda su vida, tienen dificultades para abandonar ese hábito cuando prueban un lenguaje funcional. (He visto algunos intentos bastante divertidos en F #, donde literalmente cada función era solo una cadena de frases ''let'', básicamente como si hubieras tomado un programa en C y reemplazado todos los puntos y comas con ''let''. :))

Pero otra posibilidad podría ser que no se haya dado cuenta de que está resolviendo problemas de forma trivial, lo que requeriría patrones de diseño en un lenguaje OOP.

Cuando utiliza el curry o pasa una función como argumento a otra, deténgase y piense cómo lo haría en un lenguaje OOP.

¿Hay algo de cierto en la afirmación de que la programación funcional elimina la necesidad de patrones de diseño OOP?

Sí. :) Cuando trabaja en un lenguaje de PF, ya no necesita los patrones de diseño específicos de OOP. Pero aún necesitas algunos patrones de diseño generales, como MVC u otras cosas no específicas de OOP, y necesitas un par de nuevos "patrones de diseño" específicos de FP en su lugar. Todos los idiomas tienen sus defectos, y los patrones de diseño suelen ser la forma en que trabajamos en torno a ellos.

De todos modos, puede resultarle interesante probar idiomas FP "más limpios", como ML (mi favorito personal, al menos con fines de aprendizaje), o Haskell, donde no tiene la muleta OOP para volver a caer cuando Te enfrentas a algo nuevo.

Como era de esperar, algunas personas se opusieron a mi definición de patrones de diseño como "parchar las deficiencias de un lenguaje", así que aquí está mi justificación: Como ya se dijo, la mayoría de los patrones de diseño son específicos de un paradigma de programación, o algunas veces incluso de un lenguaje específico. A menudo, resuelven problemas que solo existen en ese paradigma (vea las mónadas para FP, o las fábricas abstractas para OOP). ¿Por qué no existe el patrón de fábrica abstracto en FP? Porque el problema que intenta resolver no existe allí. Por lo tanto, si existe un problema en los idiomas OOP, que no existe en los idiomas FP, entonces claramente es un defecto de los idiomas OOP. El problema se puede resolver, pero su idioma no lo hace, pero requiere un montón de código repetitivo para que pueda solucionarlo. Lo ideal es que nuestro lenguaje de programación haga que todos los problemas desaparezcan mágicamente. Cualquier problema que todavía esté allí es, en principio, un defecto del idioma. ;)

Los comentarios de Brian sobre el estrecho vínculo entre el lenguaje y el patrón son al punto,

La parte faltante de esta discusión es el concepto de idioma. El libro de Coplien, "Advanced C ++" fue una gran influencia aquí. Mucho antes de que descubriera a Christopher Alexander y la Columna sin nombre (y tampoco se puede hablar con sensatez sobre los patrones sin leer a Alexander), habló sobre la importancia de dominar el lenguaje para aprender realmente un idioma. Utilizó la copia de cadena en C como ejemplo, mientras que (* from ++ = * to ++); Puede ver esto como una banda para una función de idioma faltante (o una función de biblioteca), pero lo que realmente importa es que es una unidad más grande de pensamiento, o de expresión, que cualquiera de sus partes.

Eso es lo que intentan hacer los patrones y los idiomas para permitirnos expresar nuestras intenciones de manera más sucinta. Cuanto más ricas son las unidades de pensamiento, más complejos son los pensamientos que puedes expresar. Tener un vocabulario rico y compartido en una gama de escalas, desde la arquitectura del sistema hasta los pequeños cambios, nos permite tener conversaciones más inteligentes y reflexionar sobre lo que deberíamos estar haciendo.

También podemos, como individuos, aprender. Que es todo el punto del ejercicio. Cada uno de nosotros puede entender y usar cosas que nunca podríamos pensar en nosotros mismos. Los idiomas, los marcos, las bibliotecas, los patrones, los modismos, etc. tienen su lugar en compartir la riqueza intelectual.

Los patrones de diseño de GoF están codificando recetas alternativas para los idiomas OO que son descendientes de Simula 67, como Java y C ++.

La mayoría de los "males" tratados por los patrones de diseño son causados ​​por:

  • clases tipificadas estáticamente, que especifican objetos pero no son objetos en sí mismos;
  • restricción al envío único (solo el argumento de la izquierda se usa para seleccionar un método, los argumentos restantes se consideran solo como tipos estáticos: si tienen tipos dinámicos, depende del método para resolverlo con enfoques ad hoc);
  • distinción entre llamadas a funciones regulares y llamadas a funciones orientadas a objetos, lo que significa que las funciones orientadas a objetos no pueden pasarse como argumentos funcionales donde se esperan funciones regulares y viceversa; y
  • Distinción entre "tipos base" y "tipos de clase".

No hay uno solo de estos patrones de diseño que no desaparezca en el Sistema de objetos Common Lisp, aunque la solución está estructurada esencialmente de la misma forma que en el patrón de diseño correspondiente. (Además, ese sistema de objetos precede al libro GoF en más de una década. Common Lisp se convirtió en un estándar ANSI el mismo año en que se publicó ese libro por primera vez).

En lo que respecta a la programación funcional, si los patrones se aplican o no depende de si el lenguaje de programación funcional dado tiene algún tipo de sistema de objetos y si se modela a partir de los sistemas de objetos que se benefician de los patrones. Ese tipo de orientación a objetos no se combina bien con la programación funcional, porque la mutación de estado se encuentra en la parte frontal y central.

La construcción y el acceso no mutante son compatibles con la programación funcional, por lo que los patrones que tienen que ver con el acceso abstracto o la construcción podrían ser aplicables: patrones como Fábrica, Fachada, Proxy, Decorador, Visitante.

Por otro lado, es probable que los patrones de comportamiento como Estado y Estrategia no se apliquen directamente en la POO funcional porque la mutación de estado se encuentra en su núcleo. Esto no significa que no apliquen; quizás se apliquen de alguna manera en combinación con cualquier truco disponible para simular un estado mutable.

Los patrones son formas de resolver problemas similares que se ven una y otra vez, y luego se describen y documentan. Entonces no, FP no va a reemplazar patrones; sin embargo, FP puede crear nuevos patrones y hacer que algunos de los patrones de "mejores prácticas" actuales sean "obsoletos".

Me gustaría agregar un par de documentos excelentes pero algo densos de Jeremy Gibbons: "Diseñe patrones como programas genéricos de tipo de datos de orden superior" y "La esencia del patrón de iterador" (ambos disponibles aquí: http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/ ).

Ambos describen cómo las construcciones funcionales idiomáticas cubren el terreno cubierto por patrones de diseño específicos en otras configuraciones (orientadas a objetos).

No puedes tener esta discusión sin abrir sistemas de tipos.

Las características principales de la programación funcional incluyen funciones como valores de primera clase, valores reales, valores inmutables, etc. No me parece obvio que los patrones de diseño OO se aproximen a cualquiera de esas características.

Esto se debe a que estas características no abordan los mismos problemas que hace la POO ... son alternativas a la programación imperativa. La respuesta de PF a la POO se encuentra en los sistemas de tipos de ML y Haskell ... específicamente tipos de sumas, tipos de datos abstractos, módulos de ML, clases de tipos de Haskell.

Pero, por supuesto, todavía hay patrones de diseño que no están resueltos por los lenguajes de FP. ¿Cuál es el equivalente de FP de un singleton? (Ignorar por un momento que los singletons son generalmente un patrón terrible de usar)

Lo primero que hacen las clases de tipos es eliminar la necesidad de singletons.

Podría pasar por la lista de 23 y eliminar más, pero no tengo tiempo para hacerlo en este momento.

OOP y los patrones de GoF tratan con los estados. La OOP modela la realidad para mantener el código base lo más cerca posible de los requisitos dados de la realidad. Los patrones de diseño de GoF son patrones que se identificaron para resolver problemas atómicos del mundo real. Manejan el problema del estado de forma semántica.

Como en la programación funcional real no existe ningún estado, no tiene sentido aplicar los patrones GoF. No hay patrones de diseño funcionales de la misma manera que hay patrones de diseño GoF. Cada patrón de diseño funcional es artificial en contraste con la realidad, ya que las funciones son construcciones de matemáticas y no de realidad.

Las funciones carecen del concepto de tiempo, ya que siempre devuelven el mismo valor, sea cual sea la hora actual, a menos que el tiempo sea parte de los parámetros de la función, lo que hace que sea realmente difícil procesar "solicitudes futuras". Los lenguajes híbridos combinan esos conceptos hacen que los lenguajes no sean lenguajes de programación realmente funcionales.

Los lenguajes funcionales están aumentando solo por una cosa: las restricciones naturales actuales de la física. Los procesadores de hoy están limitados en su velocidad de procesamiento de instrucciones debido a las leyes físicas. Se ve un estancamiento en la frecuencia de reloj pero una expansión en los núcleos de procesamiento. Es por eso que el paralelismo de instrucciones se vuelve cada vez más importante para aumentar la velocidad de las aplicaciones modernas. Como la programación funcional por definición no tiene estado y, por lo tanto, no tiene efectos secundarios, es seguro procesar las funciones de forma segura en paralelo.

Los patrones de GoF no son obsoletos. Son al menos necesarios para modelar los requisitos del mundo real. Pero si utiliza un lenguaje de programación funcional, tiene que transformarlos en sus equivalentes híbridos. Finalmente, no tiene oportunidad de hacer solo programas funcionales si usa persistencia. Para los elementos híbridos de su programa, queda la necesidad de utilizar patrones GoF. Cualquier otro elemento que sea puramente funcional no es necesario usar patrones GoF porque no hay estado.

Debido a que el patrón GoF no es necesario para la programación funcional real, eso no significa que los principios SOLID no deban aplicarse. Los principios de SOLID están más allá de cualquier paradigma lingüístico.

Yo diría que cuando tienes un lenguaje como Lisp con su soporte para macros, puedes crear tus propias abstracciones específicas de dominio, abstracciones que a menudo son mucho mejores que las soluciones de lenguaje general.