- "Programação funcional (FP) é difícil de aprender, mas fará com que seu código produza menos surpresas desagradáveis"
- Em FP, "less is more"
- Resolve o problema de Null Reference (com Maybe/Option)
- FP tem uma curva de aprendizado íngreme
- O futuro de FP
- Para desenvolver mais com menos desenvolvedores, é preciso usar todas as ferramentas possíveis, e FP é o caminho para isso
- Empresas nada glamourosas como a nossa têm dificuldade para contratar desenvolvedores. Mas passa a ser possível contratar desenvolvedores de ponta que querem trabalhar em uma base de código FP
- Ao adotar FP, a qualidade e a robustez melhoram, e o tempo gasto com bugs que não acontecem em FP será reduzido
- O fato de recursos de FP começarem a aparecer cada vez mais em linguagens mainstream mostra que a indústria de software está se preparando para uma mudança de paradigma
- Ainda será necessário muito trabalho até que a indústria faça a transição completa, mas como as vantagens disso são claras, não há dúvida sobre para onde estamos indo
13 comentários
Parece mesmo que a curva de aprendizado é alta. Até nos comentários há conteúdo mostrando que algumas pessoas realmente não entendem completamente programação funcional. Claro, também há comentários escritos por quem entende bem. Programação funcional é difícil; eu também ainda estou estudando isso. snif snif
Só poderemos voltar a falar da necessidade de FP quando surgirem casos em que a linguagem de programação deixe de ser apenas uma preferência da equipe de desenvolvimento e passe a ser uma questão de sobrevivência da empresa.
Vou resumir. Em gerenciamento de memória e em alguns algoritmos, ainda não supera a programação orientada a objetos. Basta usar de forma adequada conforme a situação e o custo.
Hum... não concordo com a afirmação de que a curva de aprendizado é íngreme.
Para começar, é simplesmente fácil, reduz a margem para erros e, portanto, aumenta a produtividade.
Isso já basta, né?
É difícil formalizar perfeitamente o pensamento e o trabalho humanos como fazem as linguagens de programação funcional pura. Quando vejo coisas como
free monad, parece que algo no nível derxjsjá é o limite máximo aceitável.No FP também chega um momento em que o custo acaba sendo maior que o benefício.
Mesmo os efeitos de FP existentes basicamente só separam dados e métodos,
e só de ver como
Optionalé menos usado do que se imagina já dá para perceber que abstração de tipos é uma abstração desnecessária (a produtividade cai demais só para fazer os tipos baterem).A menos que se vá numa direção de abstrair ainda mais dados e operações, como em Clojure, há limites para aproveitar as linguagens existentes.
A imutabilidade é apenas uma ferramenta frequentemente usada no paradigma de programação funcional.
Até onde eu sei, o paradigma de programação funcional é um paradigma que busca controlar ao máximo os "efeitos colaterais" (side effects).
Ao tentar controlar os efeitos colaterais, naturalmente passa-se a dar importância a coisas como transparência referencial, imutabilidade e funções puras.
Nesse sentido, mesmo sem necessariamente usar uma linguagem de programação funcional, acho desejável ter clareza sobre os efeitos colaterais das funções ou métodos que você escreve e conseguir controlá-los adequadamente. Isso traz muitas vantagens, como reduzir o mau cheiro no código (code smell) e tornar mais fácil escrever testes unitários.
Também há textos traduzidos que explicam isso com mais detalhes.
Nessa mesma linha, um livro focado em refatorações para minimizar efeitos colaterais é Codificação Funcional Explicada de Forma Clara: domando softwares complexos com código simples. Como ele aborda o tema por uma perspectiva mais prática e voltada ao trabalho real do que teórica, vale muito a pena para quem quer escrever um bom código. Acho que, se depois de ler isso a pessoa passar a prestar muito mais atenção aos efeitos colaterais ao escrever código, o livro já terá valido plenamente o preço.
Obrigado, vou procurar e ler.
Ah! Então já tinha saído uma tradução! Vou ler!
Obrigado pela recomendação do livro!! Vou comprar e ler agora mesmo!
Esse livro é realmente muito bom!
Pela perspectiva de refatoração, ele é realmente bem prático de usar também.
Claro, também acho que programação funcional é uma boa abordagem, mas parece que não há muitas pessoas que consigam transmitir suas vantagens de forma convincente. Se só dizem que é bom, isso não toca muito, né?
A seguir, uma opinião pessoal: como todos os programas modernos são, no fim das contas, baseados em máquinas de Turing, em um nível abstrato eles podem ser amplamente divididos em funções e dados e, por isso, penso que a programação procedural também é, em sua origem, funcional. Então, qual seria a verdadeira vantagem da programação funcional em relação à procedural? Acho que é simplesmente “não usar variáveis globais ou de escopo equivalente”. Graças a essa vantagem, ela também é eficiente no “isolamento entre funções” e em “computação multithread”.
Mas isso é uma vantagem que só pode ser obtida com programação funcional? Não necessariamente. Mesmo em linguagens procedurais, o isolamento em nível de classes e funções é recomendado por meio do conceito de dependency injection (algo que todos os frameworks modernos já adotam por padrão), e, na linguagem Rust, há restrições no próprio idioma que permitem buscar computação concorrente de forma conveniente.
Resumindo, linguagens funcionais são boas linguagens e uma boa metodologia, mas, em vez de serem “superiores em sentido evolutivo”, eu as vejo apenas como linguagens que, como Go ou Rust, “se esforçaram para eliminar, no nível da linguagem, possibilidades de falha, mas são difíceis de usar”.
Você quer dizer que algo como composição de funções também é possível em linguagens procedurais?
Se olharmos para a definição de "composição de funções" de forma mais restrita, pode parecer que isso só é possível em linguagens funcionais, mas, pensando bem, essa execução acaba rodando de qualquer forma sobre linguagem de máquina ou assembly, que são linguagens procedurais. Ou seja, não é uma questão de "ser possível ou impossível", mas sim de "interesses, preferências e filosofia da linguagem". Se ampliarmos a definição de "composição de funções", deixando de vê-la de forma restrita como "um recurso específico de uma linguagem específica" e passando a entendê-la como "composição entre funcionalidades lógicas", então isso é perfeitamente possível. E, como as vantagens das linguagens funcionais de fato existem, tecnologias como
rxjsesparkincorporaram isso ativamente.Como todos aprenderam em Ciência da Computação, abaixo temos o mesmo resultado, mudando apenas a forma de expressão. E a notação prefixa costuma ser frequentemente chamada de funcional.
Notação prefixa: + 1 1
Notação infixa: 1 + 1
Notação pós-fixa: 1 1 +