Para quais problemas comuns a programação funcional não é uma boa opção? [fechadas]

22

A programação funcional é um paradigma declarativo. Uma das forças do FP é que os efeitos colaterais são evitados. Dizem que, para alguns problemas, o FP não é um bom ajuste.

Para quais problemas comuns a programação funcional não é uma boa opção?

functional-programming paradigms Jonas
fonte
Ufa! Por um momento, pensei que você dissesse "é um paradigma defeituoso ". Então voltei e verifiquei.
Mark C
1
Eu acho que é mais preciso dizer que os efeitos colaterais são isolados (em Haskell de qualquer maneira) do que evitados. Mônadas permitem mudanças de estado, e uma é chamada "Estado".
Larry Coleman
Como explicou Larry Coleman, não é verdade que a programação funcional evite efeitos colaterais, mas desencorajou seu uso e, em alguns idiomas, os isola claramente. Leia, por exemplo, a Seção 7 de research.microsoft.com/en-us/um/people/simonpj/papers/…
Giorgio

Respostas:

17

Aplicativos de natureza muito estável. Os videogames são um bom exemplo, porque modelam o mundo real. Faz muito mais sentido pensar em modificar o estado do mundo em vez de reconstruir a partir do estado anterior toda vez que algo muda.

Um exemplo concreto seria mudar a saúde de um monstro depois de levar um tiro. É muito mais sensato simplesmente alterar sua saúde do que substituí-lo por um monstro totalmente novo que é o mesmo em todos os aspectos, exceto que agora ele tem menos saúde. Esse tipo de mudança compõe quase tudo no mundo dos jogos, e fazer isso de uma maneira pura e funcional não é muito intuitivo. Eu imagino que possa haver algumas penalidades significativas de desempenho, pelo menos se você estiver fazendo isso em uma linguagem puramente funcional.

(Como observação lateral, alguns problemas nos jogos são muito adequados para programação funcional, como a IA. Uma linguagem funcional / imperativa híbrida seria uma excelente opção para esses casos.)

Matt Olenik
fonte
9
O artigo As próximas linguagens de programação mainstream: a perspectiva de um desenvolvedor de jogos defende um pl, especificamente para o desenvolvimento de jogos, onde o comportamento puramente funcional é o padrão e a mudança de estado é rastreada através de tipos, para evitar bugs. Portanto, nem todo mundo acredita que o paradigma funcional é inerentemente inadequado para a programação de jogos.
sepp2k
1
@ sepp2k, obrigado pelo link. Fico feliz em ver a perspectiva discutida por alguém que criou jogos de verdade.
Matt Olenik
3
@ sepp2k espera, eu perdi alguma coisa? Depois de ler a apresentação mais de perto, parece que Sweeney estava argumentando que a maior parte do mecanismo principal fosse escrita com código puramente funcional e que a maior parte da lógica do jogo fosse escrita imperativamente (ou pelo menos permitida) e use o STM para ajudar na simultaneidade. . Isso parece muito razoável para mim.
Matt Olenik
@ Matt: Não, você está certo, ele diz que a parte da lógica do jogo conterá um estado mutável. No entanto, isso não impede a linguagem de rastrear a mutabilidade através de tipos (o que ele propõe na seção "reflexões"). É claro que "rastrear o estado através dos tipos" não é igual a "funcional", então eu posso ter formulado meu comentário anterior de maneira otimista demais.
sepp2k
@ sepp2k certo, entendo o que você quer dizer.
Matt Olenik
17

A programação incorporada em tempo real é sobre os efeitos colaterais. Interagindo com io digital e analógico, temporizadores, portas seriais e paralelas, tudo de interessante é feito chamando funções com efeitos colaterais.

AShelly
fonte
3
Bem, se você quer dizer apenas a interface de hardware, duvido que outra coisa que não seja C / C ++ seja uma boa escolha. No entanto, na camada superior, idiomas como o Erlang são usados ​​algumas vezes, especialmente em sistemas de telecomunicações. Erlang é uma linguagem funcional projetada para sistemas embarcados em tempo real críticos e tolerantes a falhas.
Jonas
@Jonas: Erlang pode minimizar a mutação, mas depende muito da IO para transmitir mensagens, o que é, obviamente, um efeito colateral.
quer
11

Eu diria que a programação da GUI não é uma boa opção para a programação funcional. As GUIs geralmente são muito stateful e é muito mais fácil modelá-las / gerenciá-las usando state, em vez de usar efeitos colaterais gratuitos. Certamente é possível usar uma linguagem de programação funcional para GUIs ... mas provavelmente não é uma boa ideia.

Como observado em outra resposta, os jogos geralmente são mais fáceis de gerenciar, rastreando o estado e, embora você possa escrever um jogo em uma linguagem funcional, é mais fácil e eficiente fazê-lo em uma linguagem "com estado" (por exemplo, uma orientação a objetos língua).

mipadi
fonte
-1: Você está falando sobre pureza e ignorando o uso de funções de primeira classe, por exemplo, retornos de chamada no código da GUI são muito mais fáceis com linguagens FP impuras do que com linguagens OOP.
quer
4
@ Jon Harrop: As funções de primeira classe não são exclusivas das linguagens de programação funcional. Eu ainda argumento que o estilo FP não é adequado para GUIs.
Mipadi
1
Depende de quem você pergunta. Para a maioria dos programadores funcionais, funções de primeira classe são a própria definição de programação funcional.
quer
Jon Harrop: A maioria dos programadores funcionais diria que a programação funcional é um método de descrever programas como a composição e avaliação de funções matemáticas. As funções de primeira classe são uma parte importante desse paradigma, mas as funções de primeira classe por si só não fazem uma linguagem de programação funcional (ou programa funcional). O paradigma de programação funcional se esforça para minimizar o uso de estruturas de dados mutáveis ​​e de estado, e até linguagens FP impuras incentivam esse estilo. FP é tanto sobre um estilo de programação quanto sobre recursos individuais, como funções de primeira classe e ...
mipadi
... não acho que esse paradigma seja especialmente passível de programação de GUI - linguagens orientadas a objetos são mais adequadas para GUIs, de um modo geral.
Mipadi
5

Aplicativos de negócios orientados a dados. Interface de usuário e operações simples de dados não precisam de FP.

Branimir
fonte
2
E qualquer outro aplicativo de dados / exibição, realmente. A maioria dos jogos tem tudo a ver com o estado e a alteração, e por isso não se traduz bem em um estilo funcional.
Jon Purdy
18
Sério? Eu sempre pensei que o FP seria especificamente bom para isso. Não é 99% do que esses aplicativos selecionam, agregam e projetam dados? Isso é basicamente filter, reducee map. O lance em alguns sort, partition, groupBy. Afinal, a linguagem de programação mais usada para escrever esses aplicativos é o Excel, que é uma linguagem funcional.
Jörg W Mittag
3
Aplicativos de negócios orientados a dados e aplicativos com operações simples de dados parecem ser muito bons para o FP e ouvi dizer que o FP é popular para essas coisas. Por exemplo, veja o programador funcional Adventures em Wall Street
Jonas
1
-1: você listou algum aplicativo em que o FP se destaca.
quer
2

Não é possível descartar facilmente qualquer problema definido, pois ele não é adequado para programação funcional.

Depende muito da linguagem usada para a programação funcional e de seus recursos.

Um exemplo é o já mencionado Erlang para sistemas embarcados em tempo real.

A plenitude do estado também não é um bom critério em relação à programação funcional; existem várias maneiras bem-sucedidas implementadas em linguagens de programação funcional para lidar com isso.

Os efeitos colaterais também são frequentemente mencionados contra a programação funcional. Todo programa que não é totalmente solipsista tem efeitos colaterais. Portanto, toda linguagem FP do mundo real tem alguma maneira de lidar com isso, é apenas uma questão de encapsular com elegância os efeitos colaterais do mundo.

Não há necessidade de efeitos colaterais arbitrários, como variáveis ​​globais.

Mas existem conjuntos de problemas que facilitam a entrada na programação funcional, porque eles não distorcem sua maneira familiar de ver o problema. Mas uma vez que você considere funcional, mais e mais conjuntos de problemas estarão abertos a menos efeitos colaterais.

Mesmo ao programar C, é sempre uma boa idéia reduzir ao máximo os efeitos colaterais arbitrários, como variáveis ​​globais.

Peer Stritzinger
fonte
Aplicativos de estado, como aplicativos de GUI, são realmente difíceis de serem executados de maneira funcional ou você tem alguma recomendação?
Jonas
Se você tem algum tipo de abstração de processo / thread (por exemplo, como em Erlang), pode passar seu estado em um processo.
Peer Stritzinger 28/10/10
3
Os aplicativos da GUI geralmente são criados em torno de um loop de eventos. Você pode escrever um loop de eventos muito bem em uma linguagem funcional. Se for mais complicado, você provavelmente adicionará alguns threads / processos para o processamento em segundo plano. Mas se você tem algum tipo de abstração de processo / thread (por exemplo, como em Erlang), pode passar seu estado em um processo facilmente. Continuações também podem ser úteis. Eu acho que está apenas se acostumando a fazer coisas de uma maneira funcional, até mesmo para entender as interfaces gráficas. Um dos motivos pelos quais a programação da GUI é considerada difícil hoje é que a maioria dos kits de ferramentas não se destina ao uso funcional.
Peer Stritzinger 28/10/10
1
@ Jonas: em Haskell, você usaria a mônada IO, a mônada State ou uma combinação.
Larry Coleman
1
@ Jonas: isso depende da sua definição de útil. O exemplo do wikibook usa wxHaskell, enquanto o Mundo Real Haskell usa gtk2hs. Também não tentei, pois meu aplicativo Haskell é baseado em linha de comando.
Larry Coleman