As linguagens de programação funcionais têm mais oportunidade de otimizar o tempo de compilação?

Eu estava lendo o livro "Programação Funcional para o Mundo Real". Tudo começou com a comparação entre linguagens de programação imperativas e funcionais. E afirmou como 'valores' e 'expressões' na programação funcional são diferentes de 'variáveis' e 'funções' da programação imperativa. A partir da discussão, desenvolvi uma ideia que -

As linguagens de programação funcional têm mais oportunidade de otimizar o tempo de compilação do que suas contrapartes imperativas.

É verdade?

Linguagens de programação funcional fazem muito mais otimização do tempo de compilação. Uma das razões é a pureza - a simultaneidade é trivial porque não há estado. Portanto, o compilador pode pegar duas ramificações e concurrenciá-las facilmente, sem alterar o comportamento do programa.

Ao mesmo tempo, qualquer coisa que possa ser calculada sem estado (ou seja, qualquer coisa não monádica em haskell) pode ser calculada antecipadamente pelo compilador, mas esses cálculos podem ser caros e, portanto, provavelmente são feitos apenas parcialmente.

Além disso, qualquer coisa que não seja necessária computacionalmente pode ser completamente otimizada para fora do programa.

O fato de haver, em princípio, mais possibilidades de otimização do tempo de compilação para linguagens funcionais do que para suas contrapartes imperativas é provavelmente verdade.

Mais interessante, porém, é se elas são realmente implementadas nos compiladores atuais e qual a relevância dessas otimizações na prática (ou seja, desempenho final do código idiomático da 'vida real (TM)') em um ambiente de produção, com configurações previsíveis a priori do compilador.

por exemplo, os envios de Haskell para o famoso jogo Computer Language Benchmarks (por pior que seja - mas não é como se houvesse - no momento - algo significativamente melhor por aí) dão a impressão de que uma quantidade significativa de tempo foi gasta em otimizações manuais, que confrontadas com a alegação de "possíveis otimizações do compilador devido a insert some property about FP languages here", fazem parecer que as otimizações são (atualmente pelo menos) mais uma possibilidade teórica do que uma realidade relevante.

Eu ficaria feliz em estar errado neste ponto.

No estilo funcional, o fluxo de valores através de um programa é muito, muito visível (para o compilador e o programador). Isso dá ao compilador muita margem de manobra para decidir onde armazenar valores, quanto tempo mantê-los por perto e assim por diante.

Em uma linguagem imperativa, o compilador promete ao programador um modelo em que a maioria das variáveis ​​corresponde a locais reais na memória que permanecem por um tempo definido. Potencialmente, qualquer instrução pode ler (ou gravar em!) Qualquer um desses locais; portanto, o compilador pode substituir apenas os locais de memória pela alocação de registros, mesclar duas variáveis ​​em um único local de armazenamento ou executar otimizações semelhantes depois de realizar uma análise cuidadosa de onde caso contrário, no programa essa variável pode ser referenciada.

Agora, existem duas advertências:

• A comunidade da linguagem de programação gastou (desperdiçou?) Muito esforço nos últimos cinquenta anos no desenvolvimento de maneiras inteligentes de fazer essa análise. Existem truques bem conhecidos, como coloração de registros e assim por diante, para que alguns dos casos mais fáceis sejam executados na maioria das vezes; mas isso cria compiladores grandes e lentos e uma troca constante da complexidade da compilação pela qualidade do código resultante
• Ao mesmo tempo, a maioria das linguagens de programação funcionais também não é puramente funcional; muitas das coisas que os programas realmente precisam fazer, como responder a E / S, são inerentemente não funcionais; portanto, nenhum compilador pode ficar completamente livre desses truques e nenhuma linguagem os evita completamente - até o Haskell, que é um pouco demais. puro para o meu gosto (Sua milhagem pode variar) pode apenas controlar e isolar as partes não funcionais do seu código, não evitá-las por completo.

Mas, para responder à pergunta geral, sim, um paradigma funcional oferece ao compilador muita liberdade para otimizar que ele não possui em um cenário imperativo.