Porque todas essas vantagens também são desvantagens.
Programas sem estado; Sem efeitos colaterais
Programas do mundo real são sobre efeitos colaterais e mutações. Quando o usuário pressiona um botão, é porque ele quer que algo aconteça. Quando digitam algo, querem que esse estado substitua o estado que costumava estar lá. Quando Jane Smith, na contabilidade, se casa e muda seu nome para Jane Jones, é melhor o banco de dados que apóia o processo de negócios que imprime sua folha de pagamento trata de lidar com esse tipo de mutação. Quando você dispara a metralhadora contra o alienígena, a maioria das pessoas não o modela mentalmente como a construção de um novo alienígena com menos pontos de vida; eles modelam isso como uma mutação das propriedades de um alienígena existente.
Quando os conceitos da linguagem de programação funcionam fundamentalmente contra o domínio que está sendo modelado, é difícil justificar o uso dessa linguagem.
Concorrência; Joga extremamente bem com a crescente tecnologia multi-core
O problema é apenas empurrado. Com estruturas de dados imutáveis, você tem segurança de encadeamento barata, ao custo de possivelmente trabalhar com dados obsoletos. Com estruturas de dados mutáveis, você tem o benefício de sempre trabalhar em dados novos, ao custo de ter que escrever uma lógica complicada para manter os dados consistentes. Não é como se um deles fosse obviamente melhor que o outro.
Os programas geralmente são mais curtos e, em alguns casos, mais fáceis de ler
Exceto nos casos em que são mais longos e difíceis de ler. Aprender a ler programas escritos em um estilo funcional é uma habilidade difícil; as pessoas parecem muito melhores em conceber os programas como uma série de etapas a serem seguidas, como uma receita, e não como uma série de cálculos a serem realizados.
A produtividade aumenta (exemplo: Erlang)
A produtividade precisa aumentar muito para justificar as enormes despesas de contratação de programadores que sabem como programar em um estilo funcional.
E lembre-se, você não quer jogar fora um sistema em funcionamento; a maioria dos programadores não está construindo novos sistemas a partir do zero, mas mantendo sistemas existentes, a maioria dos quais foi construída em linguagens não funcionais. Imagine tentar justificar isso para os acionistas. Por que você descartou seu sistema de folha de pagamento em funcionamento existente para criar um novo com o custo de milhões de dólares? "Porque a programação funcional é impressionante" é improvável que encante os acionistas.
A programação imperativa é um paradigma muito antigo (tanto quanto eu sei) e possivelmente não é adequado para o século XXI
A programação funcional também é muito antiga. Não vejo como a idade do conceito é relevante.
Não me interpretem mal. Adoro programação funcional, entrei para essa equipe porque queria ajudar a trazer conceitos da programação funcional para o C # e acho que a programação em um estilo imutável é o caminho do futuro. Mas existem enormes custos para a programação em um estilo funcional que não pode simplesmente ser desperdiçado. A mudança para um estilo mais funcional acontecerá lenta e gradualmente ao longo de décadas. E é isso que será: uma mudança para um estilo mais funcional, não um abraço generalizado da pureza e beleza de Haskell e o abandono do C ++.
Eu construo compiladores para ganhar a vida e definitivamente estamos adotando um estilo funcional para a próxima geração de ferramentas de compilador. Isso porque a programação funcional é fundamentalmente uma boa combinação para os tipos de problemas que enfrentamos. Nossos problemas consistem em coletar informações brutas - strings e metadados - e transformá-las em strings e metadados diferentes. Nas situações em que ocorrem mutações, como se alguém estivesse digitando no IDE, o espaço do problema se presta inerentemente a técnicas funcionais, como a reconstrução incremental de apenas as partes da árvore que foram alteradas. Muitos domínios não possuem essas boas propriedades que os tornam obviamente acessíveis a um estilo funcional .