Programação funcional: meça sete vezes, corte uma vez

Boa tarde Recentemente, ouvi muitas vezes que o pôr do sol da OLP chegou. Hoje, mais e mais pessoas estão se mudando para um paradigma funcional. Em breve, as pessoas que escreverem em C ++ / C # / Java não serão deixadas. É isso mesmo? Eu acho que não. Na minha opinião, o uso impensado do FP (programação funcional) pode se tornar demorado e uma dor de cabeça extra, o que é completamente incompatível com as decisões de design atuais. Vamos ter certeza disso!



Quero observar: não se trata de expressões lambda em Java / Python, mas de um FP mais avançado como Haskell ou Scala com cats / scalaz.

Então, afirmo que:

1. O AF está longe de ser aplicável em qualquer lugar.
2. Traz dor de cabeça quando integrado a soluções prontas.
3. Passar um tempo com AF nem sempre é sábio.

Analisaremos esses pontos com mais detalhes e avaliaremos a escala da tragédia.

1. AF está longe de ser aplicável em qualquer lugar

Isso parece surpreendente, mas nem todo mundo entende isso. Além disso, idiomas como C estão muito longe do pôr do sol. Muito além de Haskell ou Scala. Dê uma olhada em qualquer mecanismo de jogo. Com 90% de probabilidade, a maior parte está escrita em C. Dê uma olhada no firmware de qualquer dispositivo doméstico em seu apartamento. Provavelmente isso é novamente C! Sistemas operacionais? Claro que C.

Por que isso está acontecendo? O fato é que tudo isso funciona diretamente com ferro. O ferro não conhece nenhuma função de ordem superior. O ferro é um conjunto de registros (que já é um estado mutável), interrompe (novamente, que mudam de estado) e comandos que transferem zeros e uns de uma célula para outra.

Obviamente, você pode usar a abstração e esquecer todas essas coisas de ferro. Mas, em primeiro lugar, isso nem sempre é razoável. Se o nosso programa é bastante simples, não faz sentido fechar com algumas camadas de abstração. Em segundo lugar, geralmente nesses programas, a velocidade do trabalho é colocada em uma das posições principais. Portanto, o custo adicional de "explicar" a glândula FP arruinará completamente os benefícios do seu desenvolvimento. AF não pode se manifestar aqui.

2. Traz uma dor de cabeça ao integrar com soluções chave na mão

Cada linguagem de programação que se preze tem um grande número de soluções prontas. Em C #, é, por exemplo, Entity Framework e .Net. Em Java, esses são Hibernate e Spring. E quase toda estrutura visa trabalhar no nosso estilo usual de POO. Quase sempre, essas soluções têm estados variáveis ​​e são completamente inadequadas para trabalhar com transições de fase pura.

Qualquer programador funcional hard-core dirá que você precisa jogar fora essas soluções e trabalhar sem elas. Ok Vamos descobrir como referência o que vamos perder com essa decisão:

1. Quase sempre, essas decisões resultam em código padrão.
2. Estamos perdendo uma enorme camada de funcionalidade. Obviamente, podemos pegar uma biblioteca pronta para trabalhar em um paradigma funcional. Mas quase sempre essa solução é muito menos popular, o que significa que não pode oferecer metade de todas as possibilidades de soluções populares.
3. Os produtos acabados que usam essa solução precisarão ser quase completamente refatorados.
4. Estamos perdendo uma solução bem testada e altamente determinística. Em vez disso, estamos nos movendo em direção ao desconhecido. Existem problemas nas soluções populares? Claro! Mas sobre eles, como regra, tudo se sabe há muito tempo. Em nossa nova abordagem, isso definitivamente não acontecerá.

De fato, a lista continua por muito tempo. Na minha opinião, a totalidade das perdas torna a FA, pelo menos, nem em toda parte e nem sempre adequada.

3. Passar tempo com AF nem sempre é sábio

O que é surpreendente, no entanto, muitas vezes os programadores não vêem o que está por trás do código. Nem sempre uma linguagem de programação e um paradigma determinam a qualidade de um produto. Na parte de trás, tudo vai para contêiner. Quase não é importante o que você escreve: Python, Java, Scala. O código em qualquer um desses idiomas pode ser agrupado em uma imagem e entregue como um contêiner.

Nesse mundo, não é tão importante o que está dentro do contêiner se ele atender a todos os requisitos estabelecidos. É mais importante aqui como todo o sistema está organizado. Surge a pergunta: você tem certeza de que seu tempo deve ser investido no estudo de PF com sua teoria de categorias? Pode valer a pena investir no desenvolvimento da arquitetura geral do sistema. Além disso, é muito mais fácil encontrar pessoas sem conhecimento de FP que estão prontas para fornecer esses contêineres.

Imagine essa situação. Você senta à noite e estuda toda a teoria. Você assiste a vídeos no YouTube, lê livros, mergulha nos cálculos matemáticos. Com o tempo, você já pode criar um aplicativo pequeno, mas nem tudo está claro. Você começa a praticar mais: pegue livros mais avançados, participe de reuniões, converse com colegas sobre os altos. Mas então um projeto real apareceu. Com seu conhecimento, você assume um papel de liderança neste projeto. A vida é boa! E assim você escreveu o serviço perfeito. Apenas um problema permanece. O que fazer depois? Como configurar o processo de automação? Como configurar o balanceamento inteligente? Como encontrar seu outro serviço? Você pode simplesmente não ter uma resposta para essas perguntas! Você ainda tem certeza de que o AF é tão necessário para você?

Conclusões

Na verdade, tenho uma atitude extremamente positiva em relação à FA. Tudo o que quero dizer é uma ferramenta que está longe de ser sempre e em qualquer lugar. Na minha opinião, um engenheiro não deve pensar em categorias como / não gostar. Em vez disso, deve haver as razões mais objetivas para o uso desta ou daquela solução.

Antes de estudar / introduzir um paradigma funcional, deve-se fazer pelo menos três perguntas: a possibilidade de aplicar em sua área profissional, o quanto isso pode afetar quando integrado a soluções prontas e se o tempo e os recursos gastos serão pagos. Se você não tiver um ataque de pânico por nenhum desses problemas, poderá colocá-lo em serviço.

Obrigado pela atenção!