¿Cree que el lenguaje funcional es bueno para las aplicaciones que tienen muchas reglas comerciales pero muy pocos cálculos?

Question

Estoy convencido de que la programación funcional es una excelente opción cuando se trata de aplicaciones que requieren una gran cantidad de cálculos (extracción de datos, AI, nlp, etc.).

Pero, ¿es aconsejable utilizar la programación funcional para una aplicación empresarial típica donde existen muchas reglas de negocio pero no mucho en términos de computación?

Por favor, ignore el hecho de que hay muy pocas personas que usan programación funcional y que es algo difícil.

Gracias

Answer 1

Los lenguajes de programación funcionales como Clojure y Scala son buenos para cualquier cosa. En cuanto a Haskell, una programación experimentada de Haskell probablemente podría sustituir a Haskell con cualquier idioma por cualquier problema: eficiente o no. No sé si hay un lenguaje de programación funcional que pueda considerarse/mejor/fuera de todos los idiomas para este problema específico, pero tenga la seguridad de que funcionará y muy bien en eso.

Además, Clojure y Scala se implementan en la JVM. Entonces, técnicamente, ellos/están/en una plataforma empresarial.

Answer 2

¿Cuáles son las reglas de negocio, si no funciona? La aplicación de reglas se puede expresar como la aplicación de una función a un conjunto de datos. También se puede combinar con polimorfismo. p.ej. a través de funciones genéricas (el envío múltiple también puede ser útil) y la herencia.

El código es datos, los datos son el código, y ambos deben ser como el agua.

Answer 3

Supongo que cuando hablas de muchas reglas de negocio piensas en el desarrollo de aplicaciones. Desarrollo de aplicaciones en el sentido de que desea modelar un flujo de trabajo del mundo real. A diferencia de la programación de vanilla, el desarrollo de aplicaciones implica mayores niveles de responsabilidad (particularmente para la captura y prueba de requisitos). Si es así, recomiendo encarecidamente ver si puede aplicar el desarrollo impulsado por dominio. Una opción natural para el desarrollo impulsado por dominio es un enfoque orientado a objetos. Esto y el hecho de que muchos programadores son decentes en la programación orientada a objetos es una de las razones de su popularidad en el desarrollo de aplicaciones. Sin embargo, esto no significa que los proyectos a gran escala del mundo real siempre se escriban de esta manera (lea http://www.paulgraham.com/avg.html).

Answer 4

Hace más de un año profundicé un poco en Haskell y también probé algunas cosas que consideraría un problema comercial típico (para decirlo sin rodeos, dado un número de valores, ¿cuál es la respuesta correcta?). Por lo tanto, diría que sí, que debería poder modelar una serie de problemas comerciales con la programación funcional.

Personalmente no pude encontrar la misma obviedad en Haskell a la que puedo aplicar un enfoque funcional OO + como con C#, pero esto podría deberse a que no he hecho mucho con Haskell y mucho más con C#.

Luego está la forma de comunicarse con un cliente. Mi experiencia es que muchos de ellos piensan en términos estrictamente cronológicos, lo que favorece la programación imperativa. Incluso al entrar en modelos de cambios de estado, etc., puede perder un cliente extraño. Pensar a lo largo de las composiciones de funciones y las mónadas que pueden representar las operaciones cronológicas de la empresa probablemente podría estar más allá de muchos, muchos clientes.

De cualquier manera, puede encontrar mi ejemplo de negocio-y here.

Answer 5

Por lo que he visto, Scala parece que maneja Java normal bien.Por lo tanto, cualquier cosa que Java pueda manejar para los negocios, Scala también podría hacerlo.

En el lado .NET, F # es otro gran ejemplo de un lenguaje funcional que funciona bien para aplicaciones "comerciales". En pocas palabras, F # puede hacer todo lo que C# puede hacer, y más, más fácil.

Pero para ambos idiomas, el lado "programación en el lado grande" tiende a tomar prestado de OOP. No es que haya algo de malo en mezclar cosas, pero quizás eso no es lo que preguntaste. Si quiere apegarse a un enfoque más funcional, y decir, no usar objetos, podría encontrarse con un poco más de molestia porque el soporte de herramientas no estará en el mismo nivel. Con idiomas que se integran fácilmente con .NET/Java, ese no es un problema tan grande.

En cuanto a "¿es prudente?": Eso depende del proyecto, la empresa y otros factores ambientales. Parece que un "patrón empresarial" común es que el código debe ser extremadamente simplificado para que cualquiera pueda trabajar en él. En ese caso, puede involucrar a personas que piensen que el uso de una lambda hace que sea muy difícil de entender para otros.

Answer 6

Es posible que desee comprobar iTasks system, que es una biblioteca para el lenguaje funcional Clean y está diseñado exactamente para expresar el flujo de trabajo y los procesos de negocio.

Answer 7

Pero, ¿es aconsejable utilizar la programación funcional para una aplicación empresarial típica donde hay muchas reglas de negocio pero no mucho en términos de computación?

Las reglas de negocio son solo computación y a menudo puede expresarlas de forma más sucinta y clara mediante programación funcional.

Un número creciente de aplicaciones empresariales están escritas en lenguajes funcionales. Citrix XenDesktop y XenServer se basan en una pila de herramientas escrita principalmente en OCaml. El motor de búsqueda MyLife People está escrito en OCaml. Somos una empresa pequeña, pero todo nuestro software LOB (por ejemplo, transacciones con tarjetas de crédito, cuentas, análisis web) está escrito en F #. Los anuncios de Microsoft en Bing usan el código F #. Tal vez el ejemplo más obvio sea el que usa versiones recientes de C# y .NET porque casi con seguridad usan conceptos funcionales (por ejemplo, delegados).

Si te refieres a lenguajes funcionales más exóticos como Clojure, Scala y Haskell, entonces creo que algunas personas los están usando, pero yo no tengo ningún detalle.