Por que o atual entusiasmo pela programação funcional? [fechadas]

Uma das principais inovações no FP que resultou na "explosão" de interesse são as mônadas.

Em janeiro de 1992, Philip Wadler escreveu um artigo chamado A Essência da Programação Funcional , que introduziu as mônadas na programação funcional como uma maneira de lidar com IO.

O principal problema com linguagens de programação puras, preguiçosas e funcionais foi a utilidade em lidar com IO. É um dos membros do "Awkward Squad" na programação, porque "preguiça e efeitos colaterais são, do ponto de vista prático, incompatíveis. Se você quiser usar uma linguagem preguiçosa, ela tem que ser uma linguagem puramente funcional; Se você quiser usar efeitos colaterais, é melhor usar uma linguagem restrita ". Referência

O problema com IO antes das mônadas era que manter a pureza não era possível para programas que eram realmente úteis para qualquer coisa. Por IO, queremos dizer qualquer coisa que lide com a mudança de estado, incluindo a entrada e saída do usuário ou do ambiente. Na programação funcional pura, tudo é imutável, para permitir preguiça e pureza (livre de efeitos colaterais).

Como as mônadas resolvem o problema de IO? Bem, sem discutir muito as mônadas, elas basicamente pegam o "Mundo" (o ambiente de tempo de execução) como entrada para a mônada e produzem um novo "Mundo" como saída, e o resultado: digite IO a = Mundo - > (um mundo).

O FP, portanto, entrou cada vez mais no mainstream, porque o maior problema, IO (e outros) foi resolvido. A integração em linguagens OO existentes também está acontecendo, como você sabe. O LINQ é monads, por exemplo, através e através de.

Para mais informações, recomendo ler sobre mônadas e os artigos mencionados em minha resposta.

Um dos principais problemas ao programar linguagens tradicionais como C, Java, C #, assembler, etc. é que você tem uma seqüência de passos que você deve seguir para realizar uma determinada tarefa porque você precisa ter preparado todas as dependências primeiro e as dependências anteriores

Um exemplo: para fazer A, você deve ter B e C presentes e B depende de D e E, resultando em algo como

• D
• E
• C
• B
• A

porque você precisa preparar os ingredientes antes de usá-los.

Idiomas funcionais, especialmente os preguiçosos, transformam este de cabeça para baixo. Permitindo que A diga que precisa de B e C, e deixe a linguagem descobrir quando obter B e C (o que, por sua vez, requer D e E), todos avaliados quando necessário para avaliar A, você pode criar um conjunto muito pequeno e conciso blocos de construção, que resultam em programas pequenos e concisos. As linguagens preguiçosas também permitem o uso de listas infinitas, pois apenas os elementos realmente utilizados são calculados e sem a necessidade de armazenar toda a estrutura de dados na memória antes de poder usá-la.

O truque realmente legal, é que esse mecanismo automático "oh, eu preciso de um B e um C" é escalável porque não há restrição - como no programa seqüencial - sobre onde e quando isso a avaliação pode acontecer, por isso pode acontecer ao mesmo tempo e até em diferentes processadores ou computadores.

Por que as linguagens funcionais são interessantes - porque o mecanismo "o que fazer quando" é assumido pelo sistema de tempo de execução, em oposição ao programador ter que fazê-lo manualmente. Essa é uma diferença tão importante quanto a coleta automática de lixo do Java para o C, e uma das principais razões pelas quais é mais fácil escrever softwares multiencadeados robustos e escalonáveis em Java do que em C. É ainda mais fácil escrever robustos, software multi-thread escalonável em linguagens funcionais ...

No final dos anos 80 e início dos anos 90, os computadores tornaram-se poderosos o suficiente para a OOP no estilo Smalltalk. Hoje em dia os computadores são poderosos o suficiente para o FP. O FP está programando em um nível superior e, portanto, com frequência - embora seja mais agradável programar - e não a maneira mais eficiente de resolver um determinado problema. Mas os computadores são tão rápidos que você não se importa.

O prorgamming de vários núcleos pode ser mais fácil com linguagens de programação puramente funcionais, já que você é forçado a isolar o código de mudança de estado.

Além disso, as bordas da linguagem de programação estão borradas hoje. Você não precisa desistir de um paradigma se quiser usar outro. Você pode fazer FP nas linguagens mais populares, então a barreira de entrada é baixa.

Necessidade de hoje para computação distribuída.

O FP usa funções como blocos de construção, que não possuem estado, portanto invocá-los n vezes com os mesmos parâmetros deve retornar sempre o mesmo valor, eles não têm efeitos colaterais.

Assim, você pode enviar a mesma função para um monte de máquinas para executar e fazer o trabalho em paralelo.

No paradigma OO, isso é um pouco mais difícil, porque os blocos de construção são objetos, que são quase sempre definidos com estado. Se você invocar várias vezes o mesmo método, deve ter cuidado ao sincronizar os dados internos para evitar corrupção de dados. Embora ainda seja possível, o paradigma FP funciona melhor que o OO em alguns cenários em que a computação precisa ser distribuída.

O advento do FP (e do NoSQL, em certa medida) vem depois das histórias sobre resultados surpreendentes de computação em centenas de milhares de computadores trabalhando em paralelo, e como é fácil.

Mas provavelmente esse é apenas um nicho do tipo de aplicativos que precisam desse tipo de configuração. Para muitos, muitos outros aplicativos / sistemas, processuais e OO funcionam muito bem.

Tudo está prestes a expandir nossos horizontes de programação e retomar esses conceitos que antes pensávamos não ir além da academia.

Eu aprendi a programar em Lisp anos atrás, e naquela época eu não sabia que era mesmo FP. Até agora eu esqueci quase tudo sobre isso, mas certamente me ajuda a entender conceitos como recursão com muita facilidade.

Estamos mudando para uma era em que o processamento de vários núcleos não é feito apenas nos bastidores dos laboratórios de ciências ou no hardware especializado. Agora está sendo feito com processadores de commodities. A programação funcional, pelo menos a maioria das variantes às quais fui exposto, geralmente tenta empurrar uma visão sobre unidades computacionais sem estado, com efeitos colaterais. Este é o paradigma quintessencial para o trabalho multi-core, já que não há necessidade de manter o estado misturado entre os processadores.

Esta é apenas uma das razões, mas é uma boa razão para ver a programação funcional tomando conta.

Acho que a principal resposta para essa pergunta é "exposição".

A programação funcional não é novidade, aprendi Haskell na universidade há 12 anos e adorei. Mas raramente consegui usar a linguagem no meu trabalho profissional.

Recentemente tem havido um número de idiomas ganhando força no fluxo principal que usa uma abordagem multi-paradigmática; F # , sendo o JavaScript um excelente exemplo.

JavaScript em particular, especialmente quando usado com uma linguagem de estrutura de estilo funcional como jQuery ou Prototype está se tornando uma linguagem cotidiana para muitas pessoas devido a todo o trabalho em websites modernos e dinâmicos. Essa exposição ao estilo funcional faz com que as pessoas percebam o poder que ele concede, especialmente quando se é capaz de retornar a um estilo imperativo à vontade.

Quando as pessoas são expostas, elas experimentam variantes mais completas de linguagens funcionais e começam a usá-las para tarefas do dia-a-dia.

Com o F # se tornando uma linguagem de primeira classe no Visual Studio 2010 e jQuery (et al) se tornando tão importante, está se tornando realístico usar essas linguagens, em vez de algo obscuro para brincar ou fazer programas isolados.

Lembre-se de que o código precisa ser passível de manutenção - uma massa crítica de desenvolvedores deve usar e oferecer suporte a idiomas para que as empresas se sintam seguras em usá-los.

Em esta palestra Anders Hejlsberg explica sua opinião sobre o assunto.

[EDITAR]

Desculpe, o link estava errado. Agora aponta para o lugar certo.

Resumo extremamente curto de alguns pontos da palestra de uma hora:

As linguagens funcionais permitem um estilo de programação mais declarativo do que as linguagens procedurais, portanto, programas escritos em FLs geralmente concentram-se mais no o que em vez de como . Por causa de sua estrutura matemática elegante, FLs também são mais fáceis de otimizar e transformar por compiladores, o que também permite a fácil meta-programação e a construção de DSLs embarcadas. Tudo isso junto torna os programas de divertimento mais sucintos e auto-documentados do que os programas processuais.

Além disso, em face da era do manycore no futuro próximo, as linguagens de programação precisam ser capazes de utilizar multi-threading / processamento de diferentes maneiras. O multiencadeamento em máquinas de núcleo único era, na verdade, um mecanismo de compartilhamento de tempo, e a arquitetura de sistemas refletia isso. Multi-threading em máquinas manycore será muito diferente. As linguagens funcionais são especialmente adequadas para paralelização, uma vez que elas evitam principalmente o estado, portanto, não é necessário se preocupar tanto com a integridade dos dados mutáveis compartilhados (porque tendem a não haver dados mutáveis compartilhados).

Eu acho que tem a ver com a estreita correlação entre o paradigma de programação funcional e a programação para a web.

O Ruby on Rails trouxe toda a abordagem de programação funcional em relevo, uma vez que ofereceu um caminho muito rápido para um aplicativo da Web funcional (heh heh). Existe uma discussão interessante sobre o SO sobre isso, e uma resposta particular se destaca:

Functional programming matches web apps very well. The web app recieves a HTTP request and produces a HTML result. This could be considered a function from requests to pages.

Compare with desktop apps, where we typically have a long running process, a stateful UI and dataflow in several directions. This is more suited to OO which is concerned about objects with state and message passing.

Dado que a programação funcional existe há muito tempo, eu me pergunto por que não vejo muitos anúncios de emprego procurando por desenvolvedores Lisp para projetos da web greenfield.

A programação funcional me dá o mesmo senso de formigamento de " wow, isso é novo " como quando eu comecei a brincar com objetos anos atrás.

Eu percebo que o FP não é um conceito novo de longe, mas também não foi o OO quando ele teve seu verdadeiro rompimento nos anos 90, quando "todo mundo" de repente pulou da programação processual. Isto foi em grande parte devido ao sucesso oportuno de Java e mais tarde C #.

Eu imagino que a mesma coisa acontecerá com o FP, uma vez que o próximo lote de linguagens comece a se espalhar da mesma maneira. Por mais que já tenham, pelo menos em alguns círculos, linguagens como Scala e F #.

Here's my questions: 1. What has contributed to the recent FP enthusiasm? Is is merely boredom with OO, or has something changed to make FP more needed than before? 2. Is this indicative of a FP future? Or is this a fad, like object orient databases?

Outros deram uma boa razão técnica.

Acho que o motivo principal pelo qual o FP está ganhando força entre os desenvolvedores médios e os tipos de gerenciadores é a promessa de permitir um uso melhor de CPUs com vários núcleos. De tudo o que li, o FP permite programação paralela mais fácil (não fácil).

O futuro uso generalizado será se a promessa for real e for cumprida.

Eu acho que é uma combinação de duas tendências:

1. Funcionalidades funcionais adicionadas a idiomas principais (por exemplo, C #).
2. Novas linguagens funcionais sendo criadas.

Há provavelmente um limite natural na primeira tendência, mas meu palpite é que qualquer nova linguagem terá que suportar programação funcional, pelo menos como uma opção, para ser levada a sério.

Costumava ser que as pessoas escreviam programas para serem executados na área de trabalho usando as APIs nativas do sistema operacional, e essas APIs eram (geralmente) escritas em C, então, na maioria das vezes, se você quisesse escrever um programa para o nativo APIs, você escreveu esse programa em C.

Eu acho que a nova inovação nos últimos 10 anos é para uma diversidade de APIs, particularmente para coisas como desenvolvimento web onde as APIs da plataforma são irrelevantes (já que construir uma página web envolve basicamente manipulação de strings). Como você não está codificando diretamente para a API do Win32 ou para a API POSIX, isso dá às pessoas a liberdade de experimentar linguagens funcionais.

É elegante e bacana e agrada seu cérebro. Tudo bem.

É também, IMHO, um bandwagon clássico. Uma solução que procura um problema.

É como todas as empresas iniciantes criadas por engenheiros deslumbrados com uma idéia favorita, que queimam brilhantemente por um tempo, mas são silenciosamente ultrapassadas por empresas baseadas em fornecer o que é necessário.

Essa é a nova ideia que eu gostaria de ver decolando, programação baseada em necessidade, não programação baseada em idéia. Talvez isso pareça banal, mas acho que, na verdade, pode ser bem criativo e elegante.

Definitivamente por causa do F #, embora às vezes seja difícil dizer qual é a causa e qual é o efeito.