Arquitectura de programación funcional

Question

Estoy familiarizado con la arquitectura orientada a objetos, incluido el uso de patrones de diseño y diagramas de clase para la visualización, y conozco la arquitectura orientada a servicios con sus contratos y enlaces de protocolo, pero ¿hay algo característico sobre un arquitectura de software para un sistema escrito en un lenguaje de programación funcional?

Sé que FP se ha utilizado para proyectos de mediana a gran escala. Paul Graham escribió la primera encarnación de Yahoo! Tienda en Common Lisp. Algunos sistemas de desarrollo de ceceo son complejos. La inteligencia artificial y los sistemas financieros escritos en lenguajes funcionales pueden ser bastante grandes. Todos ellos tienen al menos algún tipo de arquitectura inherente, sin embargo, me pregunto si tienen algo en común.

¿Qué aspecto tiene una arquitectura basada en la evaluación de expresiones? ¿Las arquitecturas de FP son más composable?

Actualización: Kyle me recordó que SICP es un buen recurso para este tema.

Actualización 2: he encontrado un buen post sobre el tema: How does functional programming affect the structure of your code?

Answer 1

El hilo común en la "arquitectura" de los proyectos que utilizan lenguajes funcionales es que tienden a separarse en capas de álgebras en lugar de subsistemas en el sentido de arquitectura de sistemas tradicionales.

Para obtener grandes ejemplos de tales proyectos, consulte XMonad, Yi y HappS. Si examina cómo están estructurados, encontrará que comprenden capas de estructura monádica con algún pegamento combinador en el medio.

Consulte también el documento The Scala Experiment que describe una arquitectura en la que un sistema se compone de componentes que se resumen en sus dependencias.

Answer 2

La coincidencia más grande que encontrará en los lenguajes funcionales está utilizando funciones para almacenar datos. Es un poco como usar funciones de acceso en un objeto sin el objeto. En cambio, la función se crea en un entorno donde tiene acceso a los datos que necesita. Ahora esta función se puede pasar y utilizar en cualquier lugar y aún así conservar la capacidad de usar los datos.

Aquí hay un ejemplo muy simple. Esto no es puramente funcional como lo hace cambiar de estado, pero es bastante común:

(define (make-counter) 
    (let ((count 0)) 
    (lambda() 
     (set! count (+ count 1)) 
     count))) 

(define x (make-counter)) 

(x) returns 1 

(x) returns 2 

...etc... 

así que tenemos una función, hacer de venta libre, que devuelve otra función que tiene el estado del contador en el interior. Podemos llamar a ese contador recién creado y observar el cambio en el interior.

Así es como se estructuran los programas funcionales. Tiene funciones que toman funciones como argumentos, tiene funciones que devuelven funciones con estado oculto, etc. Todo es mucho más limpio que gestionar la memoria usted mismo.

Answer 3

He trabajado con algunos proyectos funcionales bastante grandes. Por lo general caen en dos campos (al menos, los que he usado):

• Escalabilidad/fiabilidad/concurrencia extremas. Los modelos transaccionales se pueden construir muy estrechamente en el lenguaje. Concurrent ML es un gran ejemplo de esto, y los proyectos que lo usan son muy difíciles de equivocarse cuando se trata de la corrección de concurrencia.
• Análisis/modificación de marcos. Muchos de los patrones de diseño en los que se basan estos marcos son increíblemente fáciles de formular/construir/modificar en lenguajes funcionales. El patrón de visitante es un gran ejemplo de esto.

Answer 4

Imprimí y miré más de Design Patterns in Ocaml, y usan módulos y funtores (y objetos) para recrear los patrones de diseño normales a los que estamos acostumbrados. Es interesante, pero creo que también usan los objetos para ver realmente el beneficio de los lenguajes funcionales. FP es muy composable, parte de su naturaleza. Supongo que mi respuesta corta es usar los módulos y functors.

Mi proyecto actual es bastante grande, y separamos cada módulo por archivos --implicto en ocaml. También he estado buscando un recurso integral que podría tener algunas vistas alternativas o algunas ideas sobre un diseño realmente exitoso que surgió de un proyecto.

Answer 5

Creo que esto puede ayudar;

Algunos de los patrones desaparecen - que es decir, que están soportados directamente por características del lenguaje, algunos patrones son más simple o tener un enfoque diferente, y algunos son esencialmente sin cambios.

[AIM-2002-005] Gregory T. Sullivan, Advanced Programming Language Features for Executable Design Patterns "Better Patterns Through Reflection

22 de marzo 2002

El libro Design Patterns [GOF95] presenta 24 patrones probados por el tiempo que consistentemente aparecen en sistemas de software bien diseñados . Cada patrón es presentado con una descripción del problema de diseño las direcciones de patrón, , así como el código de implementación de muestra y consideraciones de diseño. Este documento explora cómo los patrones del "Gang of Four" o libro "GOF" como se llama a menudo , aparecen cuando se tratan problemas similares usando un dinámico, de orden superior, orientado a objetos lenguaje de programación. Algunos de los patrones desaparecen, es decir, son compatibles directamente con las características de idioma , algunos patrones son más simples o tienen un enfoque diferente, y algunos son esencialmente sin cambios.

Answer 6

Esperemos que no tan tangencial, pero probablemente interesante para cualquier persona que navegue por las respuestas a esta pregunta es esta presentación Design Patterns in Dynamic Programming de Peter Norvig.

Answer 7

Actualmente estoy trabajando en el libro "Diseño y Arquitectura en Programación Funcional". Describe muchos patrones de diseño y enfoques que existen en el mundo PF puro (el lenguaje principal es Haskell), pero no solo. El libro te enseña cómo crear grandes aplicaciones desde cero con estado puro e impuro, multihilo, red, base de datos, GUI, cómo dividirlo en capas y obtener simplicidad. También muestra cómo modelar dominios e idiomas, cómo organizar y describir la arquitectura de la aplicación, cómo probarla y mucho más.

La lista de temas incluye:

• enfoques para modelar la arquitectura utilizando diagramas;
• Análisis de requisitos;
• Modelado de dominio DSL integrado;
• Diseño e implementación de DSL externo;
• Mónadas como subsistemas con efectos;
• Mónadas libres como interfaces funcionales;
• eDSL con flechas;
• Inversión de control usando eDSL monádicos gratuitos;
• Software Transactional Memory;
• Lentes;
• Estado, lector, escritor, RWS, ST mónadas;
• Estado impuro: IORef, MVar, STM;
• Multithreading y modelado de dominio concurrente;
• GUI;
• Aplicabilidad de técnicas y enfoques convencionales como UML, SOLID, GRASP;
• Interacción con subsistemas impuros.

El libro se basa en los proyectos de Haskell que estoy investigando, especialmente una aplicación SCADA Andromeda. El código para este libro está disponible here. Mientras el libro está en desarrollo (se llevará a cabo hasta el año 2017), puedo recomendarle que se familiarice con mi artículo "Diseño y Arquitectura en FP" here (Rus).

ACTUALIZACIÓN

compartí mi libro en línea (los primeros 5 capítulos). See post on Reddit