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

Ultimamente, tenho ouvido muito entusiasmo sobre linguagens de programação funcional, no que diz respeito ao Scala, Clojure e F #. Recentemente, comecei a estudar Haskell, para aprender o paradigma do FP.

Adoro, é muito divertido e se encaixa na minha formação em matemática.

Mas será que isso realmente importa? Obviamente, dificilmente é uma idéia nova.

Aqui estão as minhas perguntas:

1. O que contribuiu para o recente entusiasmo do FP? É apenas o tédio com OO, ou algo mudou para tornar o FP mais necessário do que antes?
2. Isso é indicativo de um futuro do FP? Ou isso é uma moda passageira, como bancos de dados orientados a objetos?

Em outras palavras, alguém pode me ajudar a entender de onde isso vem e para onde pode estar indo?

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

Em janeiro de 1992, Philip Wadler escreveu um artigo chamado The Essence of Functional Programming, que introduziu 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 era útil ao lidar com E / S. É um dos membros do "Esquadrão Embaraçoso" na programação, porque "do ponto de vista prático," preguiça e efeitos colaterais são incompatíveis. Se você deseja usar uma linguagem preguiçosa, é praticamente uma linguagem puramente funcional; se você quiser usar efeitos colaterais, é melhor usar uma linguagem estrita ". Referência

O problema com o 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 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 -> (a, Mundo).

Portanto, o FP entrou cada vez mais no mainstream, porque o maior problema, IO (e outros) foi resolvido. A integração com os idiomas OO existentes também está acontecendo, como você sabe. LINQ é mônadas, por exemplo, através e através.

Para obter mais informações, recomendo a leitura sobre mônadas e os documentos mencionados na minha resposta.

Um dos principais problemas ao programar linguagens tradicionais como C, Java, C #, assembler etc. é que você tem uma sequência incômoda de etapas a serem seguidas para realizar uma determinada tarefa, pois precisa preparar todas as dependências primeiro e SUAS dependências anteriormente

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

• D
• E
• C
• B
• UMA

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

Linguagens funcionais, especialmente as preguiçosas, viram esse de cabeça para baixo. Ao deixar A dizer que precisa de B e C, e deixar o tempo de execução do idioma descobrir quando obter B e C (que por sua vez exige D e E), todos avaliados quando necessário para avaliar A, você pode criar um número muito pequeno e conciso. blocos de construção, que resultam em programas pequenos e concisos. Os idiomas preguiçosos também permitem o uso de listas infinitas, pois apenas os elementos realmente usados ​​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 bom é que esse mecanismo automático "ah, eu preciso de um B e um C" é escalável porque não há restrições - como no programa seqüencial - sobre onde e quando essa avaliação pode ocorrer, para que possa ocorrer no mesmo tempo e até em diferentes processadores ou computadores.

É por isso que as linguagens funcionais são interessantes - porque o mecanismo "o que fazer quando" é assumido pelo sistema de tempo de execução, ao contrário do programador ter que fazê-lo manualmente. Essa é uma diferença tão importante quanto a coleta automática de lixo de Java para C e um dos principais motivos pelos quais é mais fácil escrever software robusto e escalável em vários segmentos em Java do que em C. É ainda mais fácil escrever robusto, software multiencadeado escalável em linguagens funcionais ...

No final dos anos 80 / início dos anos 90, os computadores se tornaram poderosos o suficiente para OOP no estilo Smalltalk. Atualmente, os computadores são poderosos o suficiente para FP. O FP está programando em um nível superior e, portanto, com freqüência - embora seja mais agradável programar - 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.

A pré-programação de múltiplos núcleos pode ser mais fácil com linguagens de programação puramente funcionais, pois você é forçado a isolar o código de alteração de estado.

Também 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 nos idiomas mais populares, para que a barreira de entrada seja baixa.

A necessidade atual de computação distribuída.

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

Assim, você pode enviar a mesma função para várias 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 por definição stateful. Se você invocar várias vezes o mesmo método, precisará tomar cuidado ao sincronizar os dados internos, para evitar corrupção de dados. Embora ainda seja possível, o paradigma do 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 este é apenas um nicho do tipo de aplicativos que precisam desse tipo de configuração. Para muitos, muitos outros aplicativos / sistemas, procedurais e OO funcionam bem.

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

Eu aprendi a programar em Lisp anos atrás, e naquela época eu nem 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 nos movendo para uma era em que o processamento com vários núcleos não é apenas algo feito nas salas dos laboratórios científicos ou em 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 promover uma visão sobre as unidades computacionais sem estado sem efeito colateral. Esse é o paradigma por excelência para o trabalho com vários núcleos, pois não há necessidade de manter o estado misturado entre os processadores.

Essa é apenas uma das razões, mas é uma boa razão para ver a programação funcional em andamento.

Eu acho que a principal resposta para essa pergunta é 'exposição'.

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

Recentemente, houve um número de idiomas ganhando força no fluxo principal que usam uma abordagem multiparadigma; F # , JavaScript sendo exemplos principais.

O 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 sites modernos e dinâmicos. Essa exposição ao estilo funcional faz com que as pessoas percebam o poder que ele concede, especialmente quando alguém é capaz de voltar a um estilo imperativo à vontade.

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

Com o F # se tornando uma linguagem de primeira classe no Visual Studio 2010 e o jQuery (et al) se tornando tão importante, torna-se realista usar essas linguagens, em vez de apenas algo obscuro para brincar ou criar programas isolados.

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

Em essa conversa Anders Hejlsberg explica seu ponto de vista sobre o tema.

[EDITAR]

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

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

As linguagens funcionais permitem um estilo de programação mais declarativo do que as linguagens procedurais; portanto, os programas escritos em FLs geralmente se concentram mais no quê e não no como . Devido à sua estrutura matemática elegante, os FLs também são mais fáceis de otimizar e transformar pelos compiladores, o que também permite uma metaprogramação fácil e a construção de DSLs incorporadas. Tudo isso junto torna os programas funcionais mais sucintos e auto-documentados do que os programas procedimentais.

Além disso, em face da era de muitas partituras do futuro próximo, as linguagens de programação precisam ser capazes de utilizar multiencadeamento / processamento de maneiras diferentes. O multiencadeamento em máquinas de núcleo único era, na verdade, um mecanismo de compartilhamento de tempo, e a arquitetura dos sistemas refletia isso. O multiencadeamento em muitas máquinas principais será muito diferente. As linguagens funcionais são especialmente adequadas para paralelização, uma vez que evitam o estado, portanto, não é necessário se preocupar tanto com a integridade dos dados mutáveis ​​compartilhados (porque geralmente não há 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 a um grande alívio, pois ofereceu um caminho muito rápido para um aplicativo da web funcional (heh heh). Há uma discussão interessante sobre o SO sobre isso, e uma resposta específica se destaca:

A programação funcional combina muito bem com aplicativos da web. O aplicativo da web recebe uma solicitação HTTP e produz um resultado HTML. Isso pode ser considerado uma função de solicitações para páginas.

Compare com aplicativos de desktop, onde normalmente temos um processo de execução demorado, uma interface de usuário com estado e um fluxo de dados em várias direções. Isso é mais adequado ao OO, que se preocupa com objetos com passagem de estado e mensagem.

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

A programação funcional me dá a mesma sensação de " uau, isso é novo " como quando comecei a mexer com objetos anos atrás.

Eu percebo que o FP não é um conceito novo de longe, mas o OO também não aconteceu quando teve sua verdadeira ruptura nos anos 90, quando "todos" repentinamente saíram da programação procedural. Isso ocorreu em grande parte devido ao sucesso oportuno do Java e, posteriormente, do C #.

Eu imagino que o mesmo acontecerá com o FP, eventualmente, quando o próximo lote de idiomas começar a se espalhar da mesma maneira. Da mesma forma que eles já têm, pelo menos em alguns círculos, com idiomas como Scala e F #.

Aqui estão minhas perguntas: 1. O que contribuiu para o entusiasmo recente do PF? É apenas o tédio com OO, ou algo mudou para tornar o FP mais necessário do que antes? 2. Isso é indicativo de um futuro do FP? Ou isso é uma moda passageira, como bancos de dados orientados a objetos?

Outros deram boas razões técnicas.

Eu acho que a principal razão pela qual a FP está ganhando força entre os tipos médios de desenvolvedores e gerentes é a promessa de permitir um melhor uso de CPUs multinúcleo. De tudo o que li, o FP permite uma programação paralela mais fácil (não fácil).

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

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

1. Recursos funcionais sendo adicionados aos principais idiomas (por exemplo, C #).
2. Novas linguagens funcionais sendo criadas.

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

Antes, 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; portanto, na maioria das vezes, se você deseja escrever um programa para as APIs nativas, 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 (uma vez que a construção de uma página da web envolve basicamente manipulação de strings). Como você não está codificando diretamente para a API do Win32 ou da API do POSIX, isso oferece às pessoas a liberdade de experimentar linguagens funcionais.

É bacana e bacana e faz cócegas no seu cérebro. Isso é bom.

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

É como todas as empresas iniciantes fundadas por engenheiros deslumbrados com uma ideia favorita, que queimam intensamente por um tempo, mas são superadas silenciosamente por empresas fundadas em fornecer o que é necessário.

Essa é a nova idéia que eu gostaria de ver decolando, programação baseada em necessidades, não programação baseada em idéias bacanas. Talvez isso pareça mundano, mas acho que pode ser bem criativo e bacana.

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