ti-enxame.com

Por que a programação funcional não é mais popular no setor? Entende agora?

Durante meus quatro anos na universidade, temos usado muita programação funcional em várias linguagens de programação funcional. Mas também usei muita programação orientada a objetos e, de fato, uso mais as linguagens orientadas a objetos ao fazer meu pequeno projeto para me preparar para o meu primeiro trabalho. Mas, muitas vezes, desejo codificar uma linguagem de programação funcional ao executar esses projetos.

No entanto, ao procurar um emprego, é muito raro ver um trabalho em que o conhecimento de uma linguagem de programação funcional seja necessário.

Por que as linguagens de programação funcional não são mais usadas no setor? Atualmente, existem muitas novidades sobre linguagens de programação funcional, então eu me pergunto se a programação funcional está pegando no setor agora?

61
Jonas

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 empresas são muito avessas ao risco em termos de implementação de tecnologias que não são o fluxo principal e preferem investir em estruturas testadas e verdadeiras (Java, c ++, c #). É somente quando há uma necessidade comercial (como na Ericsson) que novos paradigmas são considerados. Mas mesmo no caso da Ericsson, ouvi dizer que a gerência exigia que o c ++ fosse usado e Joe Armstrong foi obrigado a codificar chamadas erlang em c ++ !! Isso deve mostrar como as empresas estão relutantes em implementar novas tecnologias!

38
ennuikiller

Eu era professor e, assim como programadores, os professores estão sempre procurando a próxima grande coisa. Quando eles acham que encontraram um, fazem dele um movimento, e todos se empilham. Como eles estão pregando para estudantes que pensam que os professores devem ser realmente inteligentes, caso contrário, por que eles seriam professores, eles não obtêm resistência.

A programação funcional é um movimento. Certamente, há muitas perguntas interessantes para investigar e muitos artigos de conferências interessantes para escrever. Não é uma idéia particularmente nova, e você pode fazê-lo em praticamente qualquer linguagem moderna, e as idéias 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 sua aljava, não a única, assim como OOP não é a única.

Minha discussão com a academia de ciência da computação é a falta de interação prática com a indústria para determinar o que realmente faz sentido no mundo real, ou seja, o controle de qualidade. Se esse controle de qualidade existisse, poderia haver uma ênfase diferente na classificação de problemas e nas diversas soluções para eles, com vantagens e desvantagens, em vez de apenas as últimas bandwagons.

67
Mike Dunlavey

Porque 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. Dessa forma, os idiomas que fazem tornam essa prioridade (a mais popular OOP)) tendem a roubar apenas alguns dos recursos mais interessantes que saem dos mais acadêmicos linguagens funcionais e, portanto, fique por dentro.

25
Fishtoaster

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

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

  • Produtividade - aprender FP é difícil, mas depois que você pega o jeito, é muito difícil vencer em termos de poder e expressividade. Provavelmente, estou escrevendo cerca de 1/10 do número de linhas para implementar qualquer parte da funcionalidade em comparação com o que eu precisaria em C # ou Java

  • Confiabilidade - funções puras são muito mais fáceis de raciocinar e testar do que objetos com estado. Portanto, 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, que traz enormes benefícios para aplicativos simultâneos do que a execução eficaz em vários núcleos. E goste ou não, rodar em múltiplos núcleos é o futuro. Consulte http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey para obter uma explicação brilhante de por que isso é tão importante

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

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

24
mikera

Falta de aplicativo matador

Ei, este aqui parece novo. (Dig dig Dig)

Eu acho que a maioria das linguagens de programação prosperou com um "aplicativo matador" - algo atraente que era exclusivo da linguagem (ou visto dessa maneira). Isso não quer dizer que toda a aceitação foi dessa aplicação , mas que levou o idioma a uma aceitação maior.

Aqui está minha visão não muito precisa de qual nicho impulsionou a adoção de alguns dos idiomas 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)
  • Objetivo-C: aplicativos iOS (antes disso, aplicativos OS X)
  • Ruby: Rails
  • C #: ASP.NET, WinForms
  • PHP: Wordpress, etc.
  • Javascript: AJAX, especialmente via frameworks
  • lua: Script de jogo, especialmente WoW

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

Uma observação muito importante sobre essa lista: o "nicho" do idioma, conforme indicado pelo aplicativo matador, fica cada vez mais específico com o passar das décadas. Observe o último na lista: Script de jogo , especificamente. Está ficando cada vez mais difícil para os idiomas obter atenção por causa da lista de coisas que já são feitas por outro idioma.

Portanto, o que qualquer linguagem funcional realmente precisa decolar é um nicho. Na realidade, ainda não existem grandes linguagens funcionais, mas há muito em 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 que você queira muitos agentes simultâneos.
  • Esquema: Educação
  • APL/J/K: Finanças (Vamos chamá-los de funcionais, pelo bem do argumento)
  • LISP comum: "IA" - é para isso que as pessoas costumam dizer que é usado, o que é uma bênção e uma maldição.

Agora, a única linguagem importante que sinto que deixei de fora dessa discussão é o Python. Python fez algo muito interessante; conseguiu sem parecer o vencedor em qualquer nicho importante. Isso poderia significa que eu estou completamente errado ao visualizar a popularidade do idioma dessa maneira, mas também pode significar que um idioma suficientemente bom pode se tornar popular sem um aplicativo matador para impulsionar a adoção e a 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 linguagens funcionais eu acho que estão em ascensão:

  • Clojure: programação na Web, esp. através do Heroku
  • Scala: Lift (ou talvez Play, hoje em dia) - JVM sem Java

Se você me perguntasse onde procurar em seguida por linguagens funcionais populares, eu diria que está procurando uma linguagem funcional com desenvolvimento de nuvem chave na mão (à la Heroku ou GAE) ou desenvolvimento de aplicativo móvel chave na mão.

12
Jesse Millikan

Pela mesma razão que o LISP nunca realmente percebeu (que comecem as guerras de fogo!). A programação funcional é um paradigma muito estranho comparado à programação imperativa e orientada a objetos. Se, como a grande maioria dos estudantes de CS, você começou com C e progrediu para C++/Java, você não deseja aprender a pensar de uma maneira completamente ortogonal à maneira como você normalmente pensa.

9
Chinmay Kanchi

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 suporta 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 que, 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 é normalmente o que fizeram ontem. Mudança, no entanto, desejável, é cara. Se uma empresa mudasse, digamos, de uma solução C #/.NET, mesmo para F #, ela teria problemas. Seus programadores (que provavelmente não são os programadores mais perspicazes por aí) teriam que aprender um novo idioma, ser proficientes em ambos e usá-los com frequência. Haveria rotinas escritas em ambos por um longo tempo. Se eles mudassem para algo como Haskell, ou se usassem C++/MFC, eles estariam mudando muito mais, e isso seria muito mais caro.

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

Portanto, para a maioria das empresas, fazer uma alteração na programação funcional seria oneroso e pagará apenas a si próprio se a redução nos custos de TI for suficiente a longo prazo, exceto que o longo prazo é potencialmente duvidoso.

6
David Thornley

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

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

Eu acho que linguagens funcionais são muito limitantes. Portanto, em vez de substituir linguagens imperativas por funcionais, as linguagens imperativas terão recursos funcionais. Hoje em dia quase toda linguagem de programação possui encerramentos e lambdas.

2
Calmarius

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

Aqui está:

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

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

1
John Fisher

O verdadeiro problema é o estado.

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

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

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

Então, a questão então se torna: a linguagem pode lidar com o estado de maneira eficiente por trás do sentido? Especialmente quando o tamanho dos dados excede em muito o tamanho da arquitetura.

Olhando para ele do lado do hardware

O sistema operacional ajudou muito nos últimos anos na visualização do espaço de endereço, para que os aplicativos não precisem se preocupar oficialmente com isso. Mas os aplicativos que não se preocupam caem na armadilha de debulhar o hardware quando a pressão da memória se torna intensa (o hardware debilitante 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 lidem bem com isso.

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

Olhando do lado da indústria:

A indústria possui muitos programadores ineficientes em todo o estado.

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

Para programas funcionais, as melhorias são mais difíceis de medir conforme você precisa melhorar as ferramentas que melhorarão os programas (estamos apenas olhando 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 tudo 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. Programadores funcionais são difíceis de encontrar. Portanto, seu modelo básico de oferta e demanda entraria em ação se a indústria mudasse para a programação de estilo funcional e isso não é algo que eles querem que aconteça (os programadores são caros o suficiente).

0
Martin York