Qual a sua opinião mais forte contra a programação funcional? [fechadas]
25
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?
Aliás, o termo "programação funcional" é usado por pessoas diferentes para significar coisas diferentes, então você precisa esclarecer qual o significado que está usando.
quer
2
Você nunca encontrará pessoas para codificar em sua base de códigos funcional. Não é uma ótima decisão de negócios, limitando seu pool de talentos.
Patrick Hughes
Respostas:
52
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.
Absolutamente. A programação funcional pura NÃO é adequada para aplicativos muito orientados ao estado. É por isso que eu gosto de linguagens híbridas que podem fazer as duas coisas. Use paradigmas funcionais para problemas funcionais, paradigmas imperativos para problemas imperativos.
Matt Olenik
8
Acordado! O estado é uma parte essencial da programação. É por isso que mesmo Haskell, em alguns aspectos, a mais pura das linguagens FP, permite o uso de estado e E / S - simplesmente impõe uma distinção entre código IO / código de estado mutável e código puro, o que é muito bom para testar e facilitar a compreensão .
Bill
8
É por isso que eu amo Haskell. Ele incentiva a minimizar esses códigos com estado. No OO, pretendo escrever códigos reutilizáveis, fáceis de entender e fáceis de testar. Na maioria das vezes, acabo com o código que não escreveria muito diferente em Haskell.
LennyProgrammers
4
"simplesmente impõe uma distinção entre código IO / código de estado mutável e código puro, o que é muito bom para testar". Você não pode nem mesmo imprimir mensagens de depuração sem contornar o sistema de tipos ou introduzir o monad creep.
quer
2
Presumivelmente, um programa de funções puras deixaria o mundo totalmente inalterado ao executá-lo?
Martin Beckett
24
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.
Talvez houvesse mais cruzamento entre linguagens funcionais se houvesse mais linguagens funcionais.
Barry Brown #
5
Você não pode ser "funcional" sem essa pureza. Depois de ultrapassar a linha, todo o conceito desmorona e você acaba com uma linguagem padrão, paralela e confusa, sem nenhuma das vantagens.
Patrick Hughes
7
Portanto, seu primeiro problema é que as linguagens funcionais não são diferentes o suficiente para ter uma vantagem uma sobre a outra, e seu segundo problema é que elas são diferentes demais para serem facilmente trocadas?
Tikhon Jelvis
2
Para mim, esta resposta parece um discurso retórico. Seu argumento seria muito mais convincente se você desse alguns exemplos.
Benjamin Hodgson
1
...roughly 10,000 languages and dialects that are enough different to annoy but only rarely enough different for one to have a truly significant advantage over the others...Não, isso soa como todos esses langs processuais. Java, Scala, Kotlin, C ++, C #, Groovy, Cheddar, ES6, Ceilão, Python, a lista continua - eles são apenas iterações chatas de C que não resolvem os problemas reais. Essa é minha opinião ranty para complementar esta resposta ranty: D
gato
17
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.
+1, apesar de às vezes me sentir da mesma maneira quando programa em linguagens imperativas de alto nível. Por exemplo, por que o fsck eu preciso criar uma única classe de método que implemente uma única interface de método em Java, em vez de apenas usar um ponteiro de função como faria em C?
dsimcha
14
Eu diria que não é que você "não consiga entender" essas abstrações, é mais que isso exige muito trabalho. Estamos acostumados a pegar uma banana e comê-la em uma linguagem imperativa; Haskell (por exemplo) faz com que você preencha um formulário de 20 páginas primeiro porque prioriza garantir que nenhuma banana seja misteriosamente comida quando você não estiver olhando. O que ajuda ao raciocinar sobre bananas, mas às vezes você está com fome.
Jrandom_hacker
4
@dsimcha: esta é uma peculiaridade do Java, e não uma tendência em linguagens imperativas de alto nível. De fato, é provável que linguagens de alto nível tenham a função de objeto de primeira classe.
Muhammad Alkarouri 28/09/11
3
A necessidade de mônadas em Haskell não decorre da pureza funcional, mas do fato de que efeitos colaterais e avaliação preguiçosa são dois grandes sabores que NÃO têm um ótimo sabor juntos. Mônadas forçam avaliação sequencial. (Realmente, eles devem ser chamados de Construtores de Computação ou algo assim. 'Mônada' é um nome ruim para qualquer pessoa que não seja um teórico da categoria.) E você pode fazer FP felizmente sem (usando conscientemente) mônadas!
precisa saber é o seguinte
4
Uma coisa a observar: dadas essas "inversões de abstração", o idioma pode ser mais limitado, mas o compilador e o tempo de execução têm mais garantias sobre o seu código e podem fazer mais. Isso é como uma coleta de lixo - em uma linguagem gc, você não pode apenas alocar espaço (o que poderia ser útil), mas, em troca, o tempo de execução pode gerenciar toda a sua memória para você, potencialmente com mais eficiência do que você poderia manualmente. É o mesmo com a pureza funcional.
Tikhon Jelvis
8
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.
Esse é um ponto logicamente válido, mas pode ser solucionado colocando "para o tipo de problemas de programação que você encontra frequentemente" na frase final da pergunta do OP. (Não importa que os leitores individuais vão encontrar diferentes problemas, desde que descrevem o que são.)
j_random_hacker
4
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.
Os programas funcionais costumam ser mais fáceis de testar. E eles são mais curtos. Então discordo. Acho que você responde a outra pergunta "Qual é a sua opinião mais forte contra a mudança para a programação funcional?".
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.
Eu acho que o seu primeiro parágrafo descreve exatamente o que há de errado com a mentalidade do FP. Não queremos "novas maneiras interessantes de avaliar o impacto do estado em nosso código". Afinal, o que isso quer dizer?!? Nós só queremos que o estado esteja lá e seja facilmente acessível, porque precisamos que ele realmente faça as coisas.
Mason Wheeler
2
O Camry que eu dirijo tem seus problemas, mas não exige que eu verifique constantemente sob o capô se há vazamentos de espaço . Haskell é mais como uma linguagem que se parece com um carro de F1, mas na verdade não pode fazer altas rotações por um período prolongado de tempo. :-P
j_random_hacker
1
@Mason Wheeler: "Não queremos novas maneiras interessantes de avaliar o impacto do estado em nosso código". Em vez disso, preferimos passar uma semana rastreando um bug muito desagradável devido a um efeito colateral indesejado (falo por experiência pessoal).
Giorgio
Brad Clawsie: Eu acho que toda a questão do controle de efeitos colaterais no FP pode servir para tornar a codificação muito mais produtiva: leva mais tempo para escrever, mas menos tempo para corrigir. Infelizmente, é preciso se esforçar bastante para aprender primeiro, e muitos programadores não têm esse pensamento de longo prazo: as coisas devem ser feitas rapidamente. Não há tempo para fazê-lo corretamente na primeira vez, mas sempre há tempo para depurar e corrigi-lo mais tarde. :-)
Giorgio
@Mason Wheeler: Do ponto de vista funcional, ter um estado compartilhado é útil apenas para fins de otimização: copiar valores requer muito tempo e memória; portanto, você compartilha um objeto de dados para evitar cópias desnecessárias. Mas impor um estado compartilhado como regra desde o início é um tipo de otimização prematura.
Giorgio
2
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.
"fácil de aprender": não acho mais difícil dominar Haskell do que dominar C ++ moderno. Acho que tendemos a considerar muito o que não estamos familiarizados.
Giorgio
1
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.
Concorde com a primeira frase, discorde da segunda. Você basicamente não pode fazer FP sem coleta de lixo.
dsimcha
Não há exigência de que o sistema de tempo de execução de um idioma não tenha gerenciamento de memória transparente (com coleta de lixo) para caber no rótulo "procedural", por isso é irônico que você tenha redigido sua segunda frase dessa maneira. BASIC é uma dessas línguas.
Huperniketes
"Você basicamente não pode fazer FP sem coleta de lixo." - Por quê?
quant_dev
+1 A programação funcional no nível mais básico é a programação sem estado. Eu não acho que exista uma linguagem que não possa fazer isso até certo ponto. Eu escrevi funções em C, C ++, Java, assembly, C # e até Basic. Tudo o que é necessário é que a função não tenha efeitos colaterais ou mantenha o estado entre as chamadas.
Michael K
Por outro lado, se o seu idioma for totalmente puro, o compilador terá mais margem de manobra nas otimizações. Além disso, o código se torna mais fácil de testar e raciocinar. Sendo funcional durante todo não dar alguns benefícios sobre uma abordagem híbrida; se você quiser que a maioria do seu código seja apátrida de qualquer maneira, é melhor ir um pouco mais longe e colher os benefícios adicionais.
Tikhon Jelvis
1
(e de longe o mais importante) A força de trabalho do programador não é treinada nesses idiomas ou estilos
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.
Sim, isso é simplesmente falso. O código Haskell geralmente está em pé de igualdade com C e Java, e muito mais rápido que Python e amigos. Também é geralmente trivial paralelizar, potencialmente dando ainda mais velocidade.
Tikhon Jelvis 8/08/11
0
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.
Penso que pessoas sem experiência anterior em programação diriam que o OOP tem uma curva de aprendizado mais acentuada do que o FP, já que o FP está mais próximo do Math. Não entendo o que você quer dizer com "A comunidade parece não escrever código tão expressivo quanto o Java", qual é o seu ponto?
Jonas
Nunca ouvi falar de linguagem funcional perdendo expressividade. Mas também nunca usei uma linguagem menos expressiva que o Java; portanto, posso ter uma definição diferente de "expressiva".
glenatron
@ Jonas - por causa de uma coisa simples: atalhos de nomes para funções, variáveis, etc ... quero dizer, por que não apenas nomear as coisas pelo que elas são ou deveriam fazer? por que "pmap"?
Belun
1
@ Belun: Isso não tem nada com programação funcional para fazer. Você deve consultar uma linguagem de programação específica. O mapa é uma função comum em muitas linguagens de programação funcionais e possui um bom nome . pmapvocê se refere pode ser uma variante paralela.
Jonas
eu disse "a comunidade parece não escrever". significa que é o que eu experimentei e isso se repete na comunidade que eu assisti. não precisa se aplicar a todos, embora eu duvide. ele tem a ver com a programação funcional, é como se o seu estilo
Belun
0
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.
Respostas:
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.
fonte
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.
fonte
...roughly 10,000 languages and dialects that are enough different to annoy but only rarely enough different for one to have a truly significant advantage over the others...Não, isso soa como todos esses langs processuais. Java, Scala, Kotlin, C ++, C #, Groovy, Cheddar, ES6, Ceilão, Python, a lista continua - eles são apenas iterações chatas de C que não resolvem os problemas reais. Essa é minha opinião ranty para complementar esta resposta ranty: DEu 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.
fonte
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.
fonte
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.
fonte
Time To Market
Difícil de eliminar um cenário de TI completo de código processual e mantras.
fonte
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.
fonte
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.
fonte
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.
fonte
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.
fonte
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.
fonte
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.
fonte
pmapvocê se refere pode ser uma variante paralela.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.
fonte