Eu diria que uma das razões pelas quais a programação funcional não é mais prevalente é a falta de base de conhecimento. Minha experiência é que as corporações são muito aversas ao risco em termos de implementação de tecnologias que não são mainstream e preferem investir em frameworks testados e verdadeiros (java, c ++, c #). É somente quando há uma necessidade de negócios (como na Ericsson) que novos paradigmas são considerados. Mas mesmo no caso da Ericsson, ouvi dizer que o gerenciamento exigia que o c ++ fosse usado e Joe Armstrong foi obrigado a codificar as chamadas em c ++ !! Isso deve mostrar como as empresas relutantes devem implementar novas tecnologias!

Eu era professor e, assim como programadores, os professores estão sempre procurando o Next Big Thing. Quando eles acham que encontraram um, eles se tornam um bandwagon, e todos se empilham. Já que eles estão pregando para estudantes que pensam que os professores devem ser realmente espertos, senão por que eles seriam professores, eles não têm resistência.

A programação funcional é uma dessas bandas. Claro que tem muitas perguntas interessantes interessantes para investigar e muitos artigos interessantes para escrever sobre conferências. Não é uma ideia particularmente nova, e você pode fazê-lo em praticamente qualquer linguagem moderna, e as ideias não precisam ser novas para serem interessantes. Também é uma boa habilidade para ter.

Dado que, a programação funcional é apenas uma seta para ter em seu quiver, não a única, assim como a OOP não é a única.

Como o maior problema no desenvolvimento de software atualmente é a capacidade de gerenciar a complexidade. Este não é o foco da maioria das linguagens de programação funcionais. Como tal, as linguagens que fazem fazem disso uma prioridade (ou seja, as linguagens OOP mais populares) tendem a roubar alguns dos recursos mais legais que saem das linguagens funcionais mais acadêmicas e assim permanecer no topo. / p>     

A programação funcional está definitivamente começando a pegar - lenta mas seguramente.

Por exemplo, a inicialização que estou criando está usando uma linguagem funcional (Clojure) como a principal linguagem de desenvolvimento pelos seguintes motivos:

• Produtividade - aprender FP é difícil, mas quando você pega o jeito, é muito difícil de bater em termos de poder e expressividade. Eu provavelmente estou escrevendo cerca de 1 / 10th do número de linhas para implementar qualquer peça de funcionalidade em comparação com o que eu teria necessário em C # ou Java

• Confiabilidade - funções puras são muito mais fáceis de avaliar e testar do que objetos com estado. Assim, você pode escrever testes melhores e validar a correção do seu código com muito mais facilidade.

• Simultaneidade - as linguagens funcionais enfatizam a imutabilidade, o que traz enormes benefícios para aplicativos simultâneos do que a necessidade de executar com eficiência em vários núcleos. E goste ou não, rodando em múltiplos núcleos é o futuro. Veja link para uma explicação brilhante de por que isso é tão importante

• Composibilidade / modularidade - as linguagens funcionais parecem se conectar a componentes mais facilmente do que sistemas OO complexos. Eu ainda não descobri todas as razões para isso, mas parte disso deriva do fato de que você não tem toda a "complexidade incidental" que os modelos OO arrastam com eles. A palestra sobre Simplicidade Radical de Stuart Halloway explora essas idéias com muito mais profundidade.

EDIT : Em resposta ao comentário de Despertar, um exemplo da "complexidade incidental" de sistemas OOP que limita a modularidade são os problemas com clonagem profunda versus clonagem superficial: você não pode compor objetos juntos e passá-los como estruturas compostas sem uma análise muito cuidadosa da semântica de clonagem e mutação. Em pequenos casos, isso é administrável, mas em sistemas complexos, rapidamente se torna um problema significativo. Este problema não existirá em primeiro lugar se você confiar em estruturas de dados funcionais puras.

Falta de aplicativo matador

Hey, este aqui parece fresco. (dig dig dig)

Eu acho que a maioria das linguagens de programação prosperou por ter um "killer app" - algo atraente que era exclusivo da linguagem (ou visto dessa forma). Isso não quer dizer que toda a aceitação foi essa aplicação, mas que levou a linguagem a uma maior aceitação.

Aqui está minha visão não muito precisa do nicho que impulsionou a adoção de algumas das linguagens que temos hoje:

• C: Funciona em todos os lugares (este foi o final dos anos 70 e 80)
• C ++: estruturas de GUI (início dos anos 90)
• Java: applets e servlets (no final dos anos 90)
• Objective-C: aplicativos iOS (antes disso, aplicativos OS X)
• Ruby: Rails
• C #: ASP.NET, WinForms
• PHP: Wordpress, etc.
• Javascript: AJAX, especialmente via frameworks
• lua: Scripts de jogos, especialmente WoW

Além disso, muitas linguagens proprietárias entraram por entre poderosas organizações de vendas (Oracle e, em menor grau, as linguagens da Microsoft), criando efetivamente seu próprio nicho.

Uma nota muito importante sobre essa lista: o "nicho" do idioma, conforme indicado pelo aplicativo matador, fica cada vez mais específico à medida que as décadas passam. Observe o último da lista: Jogo scripting , especificamente. Está ficando cada vez mais difícil para as línguas chamarem a atenção por causa da lista de coisas que já são feitas suficientemente bem por outro idioma.

Então, o que qualquer linguagem funcional precisa realmente decolar é um nicho. Na realidade, ainda não existem grandes linguagens funcionais, mas existem muitos nichos menores:

• Emacs Lisp: Uso constante desde os anos 80 no Emacs pelos desenvolvedores. ( Quase nunca usado em qualquer outro lugar.)
• Erlang: Em qualquer lugar, você quer muitos agentes concorrentes.
• Esquema: educação
• APL / J / K: Finanças (Vamos chamar isso de funcional, para o bem do argumento)
• Common Lisp: "AI" - É para isso que as pessoas costumam dizer que é usado, o que é uma bênção e uma maldição.

Agora, a única grande linguagem que sinto que deixei de fora dessa discussão é Python. Python fez algo muito interessante; Ele conseguiu sem parecer ser o vencedor em qualquer nicho principal. Isso poderia significar que estou completamente errado em ver a popularidade de idiomas dessa maneira. Também pode significar que uma linguagem suficientemente boa pode se tornar popular sem um aplicativo matador para impulsionar a adoção e aceitação, mas é muito difícil e pode levar muito tempo. (Perl tem uma história semelhante, mas veio alguns anos antes e agora tem menos aceitação.)

A partir disso, posso dizer quais idiomas funcionais eu acho que estão em ascensão:

• Clojure: programação da Web, esp. através de Heroku
• Scala: Lift (ou talvez Play, atualmente) - JVM sem Java

Se você me perguntasse onde procurar as linguagens funcionais mais populares, eu diria que esteja atento a uma linguagem funcional com desenvolvimento de nuvem pronto para uso (a la Heroku ou GAE) ou desenvolvimento de aplicativo móvel pronto para uso.

Pela mesma razão que Lisp nunca pegou (deixe os flamewars começarem!). A programação funcional é um paradigma muito alienígena em comparação com a programação imperativa e orientada a objetos. Se, como a grande maioria dos alunos de CS, você começou com C e progrediu para C ++ / Java, você tende a não querer aprender a pensar de uma maneira completamente ortogonal à maneira como você pensa normalmente.

Vamos considerar negócios e programação.

Existem empresas que usam seu software como um ativo estratégico. Isso não é típico. Para a maioria das empresas, a TI é algo que sustenta os negócios reais da empresa. É uma despesa necessária. Eles são conservadores porque sabem que, por US $ X, podem obter a TI de que precisam, enquanto, se mudarem para algo diferente, economizarão menos de US $ X se tudo correr bem e perderão muito se tudo correr mal.

Além disso, nas empresas, a coisa mais barata a fazer é tipicamente o que fizeram ontem. Mudar, no entanto, desejável, é caro. Se uma empresa mudasse de, digamos, uma solução C # /. NET, mesmo para F #, eles teriam problemas. Seus programadores (que provavelmente não são os programadores mais habilidosos por aí) teriam que aprender um novo idioma, ser proficientes em ambos e usar os dois com frequência. Haveria rotinas escritas em ambos por um longo tempo. Se eles fossem para algo como o Haskell, ou se eles estivessem usando o C ++ / MFC em primeiro lugar, eles estariam mudando muito mais, e isso seria muito mais caro.

Além disso, haverá um fornecimento de programadores C # e suporte contínuo da Microsoft por muito tempo. As atuais práticas de TI podem ser contadas. Não há o mesmo nível de suporte institucional ou garantia de disponibilidade contínua de programadores.

Você já escreve código em estilo funcional, mas não sabe.

Quando você precisa fazer testes unitários para seu código, você tende a escrever funções testáveis, que não criam nem dependem de efeitos colaterais, e sempre retorna o mesmo resultado nos mesmos argumentos (chamadas de funções puras). Essa é a principal vantagem dos programas funcionais.

Acho que as linguagens funcionais são muito limitadoras. Portanto, em vez de substituir linguagens imperativas por funcionais, as linguagens imperativas terão recursos funcionais. Hoje em dia quase todas as linguagens de programação têm closures e lambdas.

O problema real é o estado.

Linguagens funcionais não possuem estado global. A maioria dos problemas industriais exige estado em larga escala (como você representa um livro ou um conjunto de transações) mesmo que algumas funções em pequena escala não exijam (processando um razão).

Mas estamos executando código em máquinas de arquitetura Von-Neuman que são inerentemente estado-completo. Então, na verdade, não nos livramos do estado, as linguagens funcionais apenas escondem a complexidade do estado do desenvolvedor. Isso significa que a linguagem / compilador tem que lidar com o estado nos bastidores e gerenciá-lo.

Portanto, embora as linguagens funcionais não tenham um estado global, suas informações de estado são passadas como parâmetros e resultado.

So the question then becomes can the language handle the state efficiently behind the sense? Especially when the data size far exceeds the size of the architecture.

Olhando do lado do hardware

O sistema operacional ajudou bastante nos últimos dois anos a visualizar o espaço de endereçamento, para que os aplicativos não precisem se preocupar oficialmente com isso. Mas aplicativos que não se preocupam em cair na armadilha de debater o hardware quando a pressão da memória se torna intensa (o hardware debulha vai atrasar seus processos).

Como o programador não tem controle direto sobre o estado na linguagem funcional, ele deve confiar no compilador para lidar com isso e eu não vi linguagens funcionais que lidam bem com isso.

No lado oposto da moeda, o programador com estado total tem controle direto sobre o estado e pode, assim, compensar as condições de pouca memória. Embora eu não tenha visto muitos programadores que são realmente espertos o suficiente para fazê-lo.

Olhando do lado da indústria:

A indústria tem muitos programadores completamente ineficientes.

Mas é fácil medir melhorias nesses programas ao longo do tempo. Você joga uma equipe de desenvolvedores no problema que eles podem melhorar o código, melhorando a forma como o programa lida com o estado.

Para programas funcionais, as melhorias são mais difíceis de medir porque você precisa melhorar as ferramentas que melhoram os programas (estamos apenas observando como os aplicativos lidam com o estado subjacente de forma eficiente aqui, não a melhoria geral do programa).

Então, para a indústria, acho que se resume à capacidade de medir melhorias no código.

Do ponto de vista da contratação

Existem muitos programadores completos disponíveis para contratação. Os programadores funcionais são difíceis de encontrar. Assim, seu modelo básico de oferta e demanda entraria em vigor se a indústria trocasse por programação de estilo funcional e isso não é algo que eles querem que aconteça (os programadores são caros o suficiente como estão).

Eu acredito que há apenas uma resposta real para sua pergunta. Você pode se deparar com vários motivos relacionados por que essa resposta é o caso, mas essas são perguntas diferentes.

Aqui está:

• Os arquitetos de software fornecem soluções que confiam que funcionarão.
• A maioria dos arquitetos não trabalha em linguagens funcionais.
• Depois que as tecnologias e os idiomas são escolhidos, as empresas encontram pessoas que podem trabalhar com elas.

Está pegando? Tudo depende se as pessoas que estão confiantes no uso de linguagens funcionais estão se tornando arquitetos e optando por usá-las nos projetos em que trabalham.

Esta questão tem uma premissa ligeiramente errada. Pelas seguintes razões:

1. A programação funcional é, na verdade, bastante comum no setor. Mas só é usado onde programadores experientes estão disponíveis. Não se pode esperar que principiantes saibam disso. Quase todos os grandes projetos de programação estão usando, mas eles apenas o mantêm em áreas que são manipuladas por programadores experientes. Iniciantes irão lidar com os módulos fáceis que não requerem programação funcional.
2. Dada esta realidade, as empresas que estão contratando pessoas (geralmente jovens que vêm da universidade) não podem realmente pedir uma experiência de programação funcional. Qualquer pessoa em projetos que exijam programação funcional já está na mesma empresa há 15 anos.
3. As universidades estão começando a ensiná-lo, porque já sabem que o conhecimento de programação funcional será muito útil em 30 anos. Seu intervalo de tempo é de 30 anos, não o semestre normal como nas empresas.
4. Esses pontos são a razão pela qual as pessoas ficam desapontadas quando entram na força de trabalho e veem que as coisas que aprenderam na universidade não são usadas. Mas eles foram projetados para um período de 30 anos, e será útil eventualmente - é só que as empresas estão usando as coisas simples - as coisas que eles podem esperar que as pessoas saibam.
5. Além disso, você seria arrogante se pensar que, depois de alguns anos de universidade, conhece bem a programação funcional para usá-la em projetos de software reais. Comece com as coisas simples primeiro. Você não precisa realmente fazer o software mais complexo como sua primeira tarefa quando começar a trabalhar. Você acabará por chegar ao material complexo, mas isso leva tempo.

Porque é mais difícil depurar o FP.