¿Para qué problemas comunes la programación funcional no es adecuada? [cerrado]

22

La programación funcional es un paradigma declarativo. Una de las fortalezas con FP es que se evitan los efectos secundarios. Se dice que para algunos problemas FP no es una buena opción.

¿Para qué problemas comunes no es una buena programación funcional?

functional-programming paradigms Jonas
fuente
¡Uf! Por un momento pensé que habías dicho "es un paradigma defectuoso ". Luego volví y lo comprobé.
Mark C
1
Creo que es más exacto decir que los efectos secundarios están aislados (en Haskell de todos modos) que evitados. Las mónadas sí permiten cambios de estado, y uno incluso se llama "Estado".
Larry Coleman
Como explicó Larry Coleman, no es cierto que la programación funcional evite los efectos secundarios, sino que desalienta su uso y, en algunos idiomas, los aísla claramente. Lea, por ejemplo, la Sección 7 de research.microsoft.com/en-us/um/people/simonpj/papers/…
Giorgio

Respuestas:

17

Aplicaciones de naturaleza muy dinámica. Los videojuegos son un buen ejemplo porque modelan el mundo real. Tiene mucho más sentido pensar en modificar el estado del mundo en lugar de reconstruirlo desde el estado anterior cada vez que algo cambia.

Un ejemplo concreto sería cambiar la salud de un monstruo después de recibir un disparo. Es mucho más sensato simplemente alterar su salud que reemplazarlo con un monstruo completamente nuevo que sea igual en todos los sentidos, excepto que ahora tiene menos salud. Este tipo de cambios conforman casi todo en un mundo de juegos, y hacer esto de una manera puramente funcional no es muy intuitivo. Me imagino que puede haber algunas penalizaciones de rendimiento significativas, al menos si lo estás haciendo en un lenguaje puramente funcional.

(Como nota al margen, algunos problemas en los juegos se adaptan muy bien a la programación funcional, como la IA. Un lenguaje híbrido funcional / imperativo sería una excelente opción para esos casos).

Matt Olenik
fuente
99
El artículo The Next Mainstream Programming Language: A Game Developer's Perspective argumenta a favor de un pl, específicamente para el desarrollo de juegos, donde el comportamiento puramente funcional es el predeterminado, y el cambio de estado se rastrea a través de tipos, para evitar errores. Por lo tanto, no todos creen que el paradigma funcional sea inherentemente inadecuado para la programación de juegos.
sepp2k
1
@ sepp2k, gracias por el enlace. Me alegra ver la perspectiva argumentada de alguien que ha hecho juegos reales.
Matt Olenik el
3
@ sepp2k espera, ¿me perdí algo? Después de leer la presentación más de cerca, parece que Sweeney estaba argumentando que la mayor parte del motor central se escribiría con código puramente funcional, y la mayor parte de la lógica del juego se escribiría imperativamente (o al menos lo permitiría) y usaría STM para ayudar con la concurrencia. . Esto me parece muy razonable.
Matt Olenik
@ Matt: No, tienes razón, él dice que la parte lógica del juego contendrá un estado mutable. Sin embargo, eso no impide que el lenguaje rastree la mutabilidad a través de los tipos (que propone en la sección "reflexiones"). Por supuesto, "estado de seguimiento a través de tipos" no es igual a "funcional", por lo que podría haber redactado mi comentario anterior de manera demasiado optimista.
sepp2k
@ sepp2k bien, veo a qué te refieres.
Matt Olenik el
17

La programación incrustada en tiempo real tiene que ver con los efectos secundarios. Interactuando con io digital y analógico, temporizadores, puertos seriales y paralelos, todo lo interesante se hace llamando a funciones con efectos secundarios.

AShelly
fuente
3
Bueno, si solo te refieres a la interfaz de hardware, dudo que otra cosa que no sea C / C ++ sea una buena opción. Sin embargo, en la capa superior de ese idioma, a veces se usa Erlang, especialmente en sistemas de telecomunicaciones. Erlang es un lenguaje funcional diseñado para sistemas incrustados críticos y tolerantes a fallas en tiempo real.
Jonas
@Jonas: Erlang podría minimizar la mutación, pero depende en gran medida de que IO pase los mensajes, lo que, por supuesto, es un efecto secundario.
Jon Harrop
11

Yo diría que la programación GUI no es una buena opción para la programación funcional. Las GUI son generalmente muy dinámicas, y es mucho más fácil modelarlas / administrarlas usando el estado en lugar de usar un efecto secundario libre. Ciertamente es posible usar un lenguaje de programación funcional para GUI ... pero probablemente no sea una buena idea.

Como se señaló en otra respuesta, los juegos son a menudo más fáciles de administrar mediante el seguimiento del estado, y si bien puede escribir un juego en un lenguaje funcional, a menudo es más fácil y más eficiente hacerlo en un lenguaje "con estado" (es decir, orientado a objetos idioma).

mipadi
fuente
-1: Estás hablando de pureza e ignorando el uso de funciones de primera clase, por ejemplo, las devoluciones de llamada en el código GUI son mucho más fáciles con los lenguajes FP impuros que con los lenguajes OOP.
Jon Harrop
44
@ Jon Harrop: las funciones de primera clase no son exclusivas de los lenguajes de programación funcionales. Sigo argumentando que el estilo FP no es una buena opción para las GUI.
mipadi
1
Depende de a quién le preguntes. Para la mayoría de los programadores funcionales, las funciones de primera clase son la definición misma de la programación funcional.
Jon Harrop
@ Jon Harrop: La mayoría de los programadores funcionales dirían que la programación funcional es un método para describir programas como la composición y evaluación de funciones matemáticas. Las funciones de primera clase son una parte importante de este paradigma, pero las funciones de primera clase por sí solas no hacen un lenguaje de programación funcional (o programa funcional). El paradigma de programación funcional se esfuerza por minimizar el uso de estructuras de datos mutables y de estado, e incluso los lenguajes FP impuros fomentan este estilo. FP se trata tanto de un estilo de programación como de características individuales como funciones de primera clase, y ...
mipadi
... No creo que este paradigma sea especialmente adecuado para la programación GUI: los lenguajes orientados a objetos son más adecuados para las GUI, en general.
mipadi
5

Aplicaciones comerciales basadas en datos. La interfaz de usuario y las operaciones de datos simples no necesitan FP.

Branimir
fuente
2
Y cualquier otra aplicación de datos / vista, de verdad. La mayoría de los juegos tienen que ver con el estado y cambiarlo, por lo que no se traducen bien a un estilo funcional.
Jon Purdy
18
De Verdad? Siempre pensé que FP sería específicamente bueno para esto. ¿No es como el 99% de lo que esas aplicaciones seleccionan, agregan y proyectan datos? Eso es básicamente filter, reducey map. Tirar un poco sort, partition, groupBy. Después de todo, el lenguaje de programación más utilizado para escribir tales aplicaciones es Excel, que es un lenguaje funcional.
Jörg W Mittag
3
Las aplicaciones empresariales basadas en datos y las aplicaciones con operaciones de datos simples suenan muy bien para FP y he oído que FP es popular para tales cosas. Por ejemplo, ver programador funcional aventuras FA en Wall Street
Jonas
1
-1: Has enumerado alguna aplicación en la que FP sobresale.
Jon Harrop
2

No puede descartar fácilmente cualquier conjunto de problemas que no sea adecuado para la programación funcional per se.

Mucho depende del lenguaje real utilizado para la programación funcional y sus características.

Un ejemplo es el ya mencionado Erlang para sistemas embebidos en tiempo real.

La plenitud de estado tampoco es un buen criterio en contra de la programación funcional, hay varias formas exitosas implementadas en lenguajes de programación funcional para lidiar con esto.

Los efectos secundarios también se mencionan a menudo contra la programación funcional. Cada programa que no es totalmente solipsista tiene efectos secundarios. Por lo tanto, cada lenguaje FP del mundo real tiene alguna forma de lidiar con esto, solo es una cuestión de cuán elegantemente encapsular los efectos secundarios mundiales.

No hay necesidad de efectos secundarios arbitrarios como las variables globales en absoluto.

Pero hay conjuntos de problemas que hacen que sea más fácil ingresar a la programación funcional porque no tuercen tanto su forma familiar de ver el problema. Pero una vez que logras pensar funcionalmente, más y más conjuntos de problemas están abiertos a menos efectos secundarios.

Incluso cuando se programa C, siempre es una buena idea reducir los efectos secundarios arbitrarios, como las variables globales, tanto como sea posible.

Peer Stritzinger
fuente
Las aplicaciones con estado como las aplicaciones GUI son realmente difíciles de hacer de una manera funcional, ¿o tiene alguna recomendación?
Jonas
Si tiene algún tipo de abstracción de proceso / hilo (por ejemplo, como en Erlang) puede pasar su estado en un proceso.
Peer Stritzinger
3
Las aplicaciones GUI generalmente se crean alrededor de un bucle de eventos. Puede escribir un bucle de eventos bastante bien en un lenguaje funcional. Si es más complicado, probablemente agregará algunos hilos / procesos para el procesamiento en segundo plano. Pero si tiene algún tipo de abstracción de proceso / hilo (por ejemplo, como en Erlang) puede pasar su estado fácilmente en un proceso. Las continuaciones también pueden ser útiles. Creo que se está acostumbrando a hacer cosas de una manera funcional para incluso manejar las GUI. Una razón por la que la programación de la GUI se considera difícil hoy en día es que la mayoría de los kits de herramientas no están destinados a un uso funcional.
Peer Stritzinger
1
@Jonas: en Haskell, usarías la mónada IO, la mónada estatal o una combinación.
Larry Coleman
1
@Jonas: eso depende de tu definición de útil. El ejemplo de wikibook usa wxHaskell, mientras que Real World Haskell usa gtk2hs. Tampoco lo he intentado ya que mi aplicación Haskell está basada en la línea de comandos.
Larry Coleman