Qual a sua opinião mais forte contra a programação funcional? [fechadas]

A programação funcional é um dos mais antigos paradigmas de programação. No entanto, não é muito usado na indústria em comparação com paradigmas mais populares. Mas isso tem sido amplamente enfatizado na academia.

Qual a sua opinião mais forte contra a programação funcional?

O problema é que o código mais comum envolve inerentemente aplicativos corporativos de estado, jogos, interface do usuário etc. Não há problema em algumas partes de um aplicativo serem puramente funcionais; de fato, a maioria dos aplicativos pode se beneficiar em pelo menos uma área. Mas forçar o paradigma em todo o lugar parece contra-intuitivo.

O problema com a programação funcional não é a programação funcional em si - é a maioria das pessoas que faz isso e (pior) a maioria das pessoas que cria linguagens para fazê-lo.

O problema decorre do fato de que, apesar de serem muito inteligentes (às vezes francamente brilhantes), muitas pessoas são fanáticas demais por pureza, perfeição e por impor sua própria visão (geralmente bastante estreita) do mundo e programar no mundo. linguagem e todos que a usam.

Um dos resultados é uma falha no comprometimento. Isso leva (entre outras coisas) a aproximadamente 10.000 idiomas e dialetos que são diferentes o suficiente para incomodar, mas raramente são suficientemente diferentes para que um tenha uma vantagem verdadeiramente significativa sobre os outros. Muitos também olham para o mundo real e decidem que, como ele não se encaixa muito bem no modelo funcional, é basicamente errado e é melhor ignorá-lo.

A incapacidade de comprometer também levou a algumas linguagens absolutamente lindas para um tipo específico de problema (ou alguns tipos específicos de problemas), mas que realmente são péssimas para muitas outras. Parte disso é provavelmente causada pelo próprio modelo funcional, mas muito mais parece (pelo menos para mim) ser causado pelo tipo básico de personalidade que é atraído para essa área, para começar.

Isso leva a uma série de problemas. Primeiro de tudo, aprender "programação funcional" é principalmente de valor filosófico. Com a maioria dos outros tipos de idiomas, conhecer um idioma de um gênero específico é de grande ajuda para o aprendizado de outro. Se meu projeto usa a linguagem XI, geralmente posso contratar alguém que conheça a linguagem Y (mas não X) com bastante segurança. Com linguagens funcionais, isso é muito menos verdadeiro. Você pode conhecer Erlang muito bem, mas ainda acha as mônadas de Haskell completamente estranhas e incompreensíveis.

Junte o número de idiomas com a portabilidade limitada de talento entre eles e você terá uma situação feia: é quase impossível para um idioma ou dialeto formar a "massa crítica" necessária para torná-lo um uso razoavelmente geral. Isso está mudando lentamente, mas ainda é muito parecido com o Linux se tornar o sistema operacional dominante para desktop - todos os anos, as pessoas criam argumentos convincentes de que finalmente esse será o ano - e assim como as pessoas que prevêem isso a cada ano. ano por décadas, eles estarão errados mais uma vez. Isso não quer dizer que (um ou outro) nunca possa acontecer - apenas que as pessoas que olham para as previsões e pensam "não, não este ano" foram as que estavam certas até agora.

Eu acho que a razão pela qual a programação funcional não é muito usada é porque ela atrapalha demais. É difícil examinar seriamente, por exemplo, Lisp ou Haskell, sem dizer "toda essa linguagem é uma grande inversão de abstração". Quando você estabelece abstrações da linha de base que o codificador não consegue entender quando necessário, estabelece coisas que a linguagem simplesmente não pode fazer e, quanto mais funcional a linguagem, mais ela tende a ter.

Veja o Haskell, por exemplo. Em nome da pureza funcional, é necessário o uso de inversões de abstração que ninguém entende para gerenciar estado e E / S, as duas partes mais fundamentais de todo e qualquer programa de computador que interage com qualquer coisa! Isso envelhece rápido.

Com todo o respeito, acho que sua pergunta está mal colocada. A programação funcional é uma ferramenta, ou melhor, um conjunto de ferramentas úteis para resolver certos tipos de problemas. Ter uma opinião sobre isso só faz sentido no contexto de um problema ou aplicativo específico. Ter uma opinião contra isso em geral, é como ter uma opinião contra um alicate ou chave inglesa.

Mesmo que eu o tenha dominado, talvez não esteja inclinado a usar uma linguagem funcional para um produto comercial pela simples razão de que eles não são amplamente compreendidos e se eu esperava que o negócio crescesse, ficaria preocupado com a capacidade de encontrar outros desenvolvedores capazes de mantê-lo ou estendê-lo ao longo do tempo.

Não é inconcebível, e você provavelmente obteria um padrão mais alto de desenvolvedor, porque um graduado em javaschool sem habilidades reais de hackers não saberia por onde começar um projeto desse tipo, mas o pool limitado de desenvolvedores capazes certamente seria uma consideração necessária do ponto de vista de negócios.

Time To Market

Difícil de eliminar um cenário de TI completo de código processual e mantras.

Antes de tudo, não aceito nenhum dos argumentos sobre programação de estado e fp. olhe para a mônada do estado em haskell e você encontrará várias novas maneiras interessantes de avaliar o impacto do estado no seu código.

se eu fosse fazer um argumento significativo contra o FP, seria que aprender uma linguagem funcional séria como o haskell é como aprender a dirigir um carro de Fórmula 1 ... divertido e educativo, mas infelizmente inútil para a codificação industrial cotidiana, porque, em média, , seus colegas de trabalho estão dirigindo camrys e estão felizes em fazê-lo. ainda é extremamente difícil encontrar trabalho em um ambiente favorável aos FP, e eu não vejo isso mudando, a menos que alguém esteja disposto a atacar por conta própria ou procurar alguns dos conhecidos praticantes de FP.

Suponho que minha resposta me mostre como um fanboy fp. Eu sugiro dar uma linguagem fp real como haskell um giro sério antes de se preocupar em encontrar razões pelas quais você não deveria.

Sou um grande fã e defensor da programação funcional. Mas aqui estão os meus pontos:

• fácil de aprender
  Linguagens de programação como python e ruby ​​(e muitas outras linguagens) são fáceis de aprender. A programação funcional avançada, com linguagens como Haskell, Agda, Coq, ATS, etc., é bastante difícil de aprender. Alguns usam o termo "programação estruturada matemática". É fácil se você estiver familiarizado com a teoria das categorias e a matemática abstrata, mas bastante funciona se você não tem idéia do que são, por exemplo, "mônadas".

• programar com uma linguagem de script pode significar mais produtividade.
  Em algumas situações, o uso de linguagens de script como python e ruby ​​pode levar a mais produtividade. Isso significa prototipagem rápida e colagem de diferentes pacotes ou bibliotecas. Mesmo o uso de linguagens dinâmicas (por exemplo, programação dinâmica orientada a objetos) pode ser uma coisa boa nesse contexto. Normalmente, a digitação estática é melhor, mas scripts com tipos dinâmicos podem ter um efeito positivo.

• considerações de negócios A
  programação é apenas um pequeno subconjunto de projetos de software bem-sucedidos. O software precisa funcionar, os usuários precisam ser felizes e isso não depende necessariamente da linguagem de programação usada. Os gerentes precisam pensar nos benefícios e riscos ao avaliar novas tecnologias e linguagens de programação. Os novos programadores podem aprender rapidamente a nova linguagem de programação? Existe experiência na empresa com a tecnologia? Existe um risco e será difícil argumentar com a alta gerência?

No contexto comercial, a programação funcional pode ser usada em sistemas que adicionam componentes de software principais, por exemplo, componentes que não são tão críticos para a missão. Por exemplo, um banco que dificilmente mudará o software principal, mas adicionará novas peças (GUI, software de monitoramento etc.) na nova linguagem de programação. (Talvez haja exceções, mas esta é a minha experiência com bancos.)

Além disso, a programação funcional é muito útil quando a verificação formal é um benefício ou uma obrigação.

Não sou contra o FP como um paradigma útil, mas sou contra o único paradigma disponível em uma linguagem de programação.

Oferece vantagens na solução de muitos problemas. No entanto, o FP pode e foi aplicado em linguagens processuais como C.

1. (e de longe o mais importante) A força de trabalho do programador não é treinada nesses idiomas ou estilos
2. Muitos dos evangelistas funcionais aparecem como buracos ou bolos de frutas por causa da maneira como tentam vender o funcional. Ninguém gosta de um buraco, e ninguém vai jogar dinheiro atrás de um bolo de frutas. Veja bem, eu realmente gosto das coisas funcionais e gostaria de usá-las, mas sei que no meu local de trabalho seria a única pessoa que poderia desenvolvê-las sem gastar dinheiro em treinamento (hard sell) e quase tudo de bom referências conversação para o leitor.

O funcional surgirá quando tivermos centenas de núcleos e percebermos que os bloqueios não são dimensionados. Os dados aninhados em paralelo serão o único caminho a seguir para programas "grandes", e as funções funcionais são excelentes.

FP é legal na academia, porque é legal escrever bons programas curtos, enquanto ignora o desempenho. Não há conspiração contra isso no mundo real. Também, por exemplo, implementar algumas coisas (classificação radix, por exemplo) parece uma dor total no FP. Ah, e o código gerado é IMHExperience sloooooooooooooooooooow.

Alguns têm uma curva de aprendizado bastante íngreme, demorando muito tempo (especialmente se você vem de OOP; você bica a cabeça algumas vezes antes de começar a mudança de paradigma).

Mesmo que eu comecei a obter programação funcional (vindo de Java e indo para Clojure), ainda acho isso bastante difícil. A comunidade não parece escrever um código tão expressivo quanto o Java.

Parece que há uma pequena perda de expressividade e um pequeno aumento de complexidade.

Mesmo tendo pouca experiência com linguagens de programação funcionais (conheço alguns Haskell e Lisp), acho o paradigma FP muito poderoso e frequentemente mais elegante do que outros paradigmas. Eu gostaria de ter a oportunidade de trabalhar em um projeto sério usando FP.

A única área em que tenho sérias dúvidas sobre a eficácia do PF está em como ele pode lidar com estruturas de dados complexas que não podem ser definidas indutivamente, por exemplo, gráficos. Por exemplo, se eu tiver que implementar um algoritmo que funcione em um gráfico grande, possivelmente percorrendo o gráfico e fazendo pequenas alterações locais, pergunto-me se uma abordagem de FP pode corresponder a uma abordagem imperativa na qual o programa pode passar de nó para nó usando ponteiros.