Argumentos para programação funcional [fechado]

Recentemente, aprendi F # por diversão (sou um VB.NET/C# dev) e gosto muito do que ele tem a oferecer. Teoricamente é isso. Mas estou tendo problemas para pensar em cenários em que optaria por codificar em F # em vez de em C #. Alguma ideia?

Alguns argumentos para pura programação funcional:

• É mais fácil dividir tarefas para os sistemas multinúcleo atuais
• É mais fácil provar que seu programa está correto
• A composição funcional pode ser incrível, concisa e poderosa

Para obter um tratamento completo, consulte Por que a programação funcional é importante e Por que a programação funcional é importante .

Estou tendo problemas para pensar em cenários em que eu escolheria codificar em F # em vez de em C #. Alguma ideia?

A partir daqui :

Servidores assíncronos

• Fluxos de trabalho assíncronos para a E / S assíncrona.
• Processador de caixa de correio para a passagem segura de mensagens.
• Tipos de união para o estado do servidor e o catálogo de mensagens.
• Correspondência de padrões e recursão de cauda para as máquinas de estado.

Metaprogramação (por exemplo, análise)

• Geradores de analisador como fslex e fsyacc.
• Combinadores de analisador como FParsec.
• Padrões ativos para elegantes analisadores enrolados à mão.
• Tipos de dados algébricos para representar árvores de análise.
• Correspondência de padrões para manipular árvores, por exemplo, aplicar estágios de otimização.
• Reflexão para geração em tempo de execução de código rápido.

Computação técnica

• Funções de ordem superior para código algorítmico elegante e rápido.
• Tipos de dados algébricos e correspondência de padrões para manipulação simbólica.
• Interoperabilidade para diversas bibliotecas .NET.
• Interatividade usando F # interativo.
• Expressões de computação para massagear dados.
• Unidades de medida para correção aprimorada.

Aplicações GUI

• Modele como mensagem assíncrona passando entre o código da interface do usuário e o código lógico do aplicativo.
• Funções de ordem superior permitem definir interfaces de usuário declarativamente.

Programação lógica

• Coleções persistentes para fácil retorno.
• Cauda exige confiabilidade.
• Generalização automática para fácil programação genérica.

Teste

• Execute testes de unidade interativamente.
• BDD significa escrever um intérprete.
• Boa linguagem de script para escrever chicotes de teste e visualizar resultados.

atuação

• inline para abstração de ordem superior gratuita.
• A cauda exige máquinas de estado rápidas.
• Estruturas de dados puramente funcionais para baixa latência.
• Metaprogramação para geração de código otimizado.

A seguir, para que usar a programação de estilo funcional - diariamente, mais ou menos.

Fazemos muitas coisas estatísticas e atuariais com conjuntos de dados razoavelmente grandes. Os dados buscados no banco de dados são - essencialmente objetos estáticos e imutáveis. Não há razão para criar uma classe com métodos.

Cada estágio do cálculo adiciona alguns detalhes adicionais, mas não modifica essencialmente o objeto. No "final" do pipeline, estamos realmente fazendo uma redução sofisticada para calcular somas, contagens e outras coisas.

Imagina isto.

for data in summarize( enrich( calculate( some_query( criteria() ) ) ) ):
    print data

Cada "fase" do cálculo é um loop de programação funcional que executa simples leitura-cálculo-rendimento e cria um objeto composto de outras coisas, mais resultados.

(Usamos Python, daí a programação funcional usando funções de gerador.)

É mais fácil usar objetos imutáveis ​​e sem estado.

Tecnicamente, não é uma propriedade exclusiva de uma programação funcional, e o F # não é uma linguagem funcional pura. O F #, como um dos descendentes de ML, fornece uma excelente correspondência de padrões e tipos de dados algébricos. Portanto, para qualquer tarefa que exija estruturas de dados complexas, o F # é muito mais expressivo e fácil de usar que o C #.

Imagine implementar um compilador em C # e F # - representando uma árvore de sintaxe abstrata e transformá-la sobre ela é muito mais simples se sua linguagem fornecer ADTs e uma correspondência de padrões.

Ideal para o tipo de redução de mapa de paralelismo multissistema maciço e multinúcleo maciço. Muito legal, considerando que atualmente os servidores de nível básico vêm com 48 núcleos (96 com HT).

Se você quiser experimentar Haskell totalmente funcional, Erlang também tem coisas muito legais sobre isso.

Simon Payton-Jones disse sobre Haskell, ele quer ter um programa que obviamente não tem bugs, em vez de não ter bugs óbvios.

(Eu provavelmente tirei a citação um pouco, mas você entendeu)

Ao restringir os efeitos colaterais, você torna muito mais fácil provar que seu código está correto.

Uma vantagem definitiva é que é muito mais facilmente paralelizado.