A programação funcional pode ser usada para desenvolver um aplicativo corporativo completo?

Estou apenas começando a aprender programação funcional (FP). Eu venho de um mundo OOP, onde tudo são objetos, e a maioria deles é mutável. Eu tenho dificuldade em entender o conceito de que funções não têm efeitos colaterais.

Se algo não é mutável, como objetos comuns são objetos, como Funcionário ou Pessoa, representados no FP.

O FP pode ser usado para criar um aplicativo corporativo completo?

A questão não é Pode ser usado o FP na empresa? mas devemos usar o FP na empresa?

Claro que você pode. Você pode desenvolver qualquer tipo de aplicativo com qualquer tipo de linguagem de programação, por isso é chamado de "Turing complete".

Agora, para a pergunta "Deve ser usada na empresa?" Isso depende de você ou de seus empregadores, o FP pode ser realmente útil em algum tipo de aplicação e, de fato, é bastante usado: Haskell na indústria

Agora, você pode estar se perguntando "Então, por que não é usado mais?" principalmente porque outras linguagens Imperative / OO são mais comuns, e as empresas se recusam a mudar para uma linguagem mais "exótica" porque estão acostumadas a Java ou C ++.

Comecei a aprender sobre linguagens FP há alguns anos (Haskell, Scala, Scheme) e, apesar de estar longe de ser um especialista, descobri que eles podem me tornar extremamente produtivo, para certas tarefas além de C ++ ou Java .

Na IMO, alguns dos pontos fortes das línguas FP são:

• Eles tendem a ser muito concisos, mas mantêm uma semântica clara.
• Você pode usar um estilo declarativo e não precisa pensar muito nos detalhes da implementação.
• Um sistema de tipo rico como o de Haskell pode detectar muitos erros lógicos muito cedo (em tempo de compilação). Tanto quanto eu sei (na verdade não muito), SML e Ocaml oferecem vantagens semelhantes.

Até agora, achei a mudança para o paradigma FP bastante empolgante e não muito difícil depois que você passou tempo suficiente nele. (Mas quanto tempo eu gastei aprendendo C ou C ++? Bastante!)

Então, acho que, do ponto de vista técnico, faz todo sentido desenvolver um aplicativo corporativo completo usando uma linguagem de programação funcional.

Infelizmente, esse paradigma não é predominante: a maioria das empresas costuma adotar apenas tecnologias testadas, portanto elas ficam afastadas do FP até que tenham evidências suficientes de que realmente funciona, de que haja desenvolvedores, ferramentas, bibliotecas e estruturas suficientes. Portanto, é (muito) mais difícil encontrar um emprego no qual você possa fazer a programação FP em tempo integral.

Talvez a situação atual mude se o uso crescente de processadores com vários núcleos incentivar a investir mais em linguagens FP, que parecem ser bastante fortes para escrever softwares concorrentes.

Além disso, existe uma tendência de introduzir alguns recursos de FP em linguagens não funcionais comuns, como C #, C ++, para que os programadores possam usar algum FP sem a necessidade de uma mudança completa de paradigma. Talvez daqui a dez anos essas linguagens abranjam recursos FP suficientes, para que a mudança para uma linguagem puramente funcional seja muito mais fácil.

Não acho que seja necessariamente a melhor ideia. Mas isso depende da natureza da aplicação específica.

Acredito muito na filosofia de Eric Evans, como descrito em seu livro, Design Orientado a Domínio , que você deve criar um modelo de domínio que seja uma representação do problema em questão que possa ajudá-lo a resolvê-lo. Evans sugere encontrar uma linguagem de programação compatível com o problema específico em questão, por exemplo, ele menciona Fortran como uma maneira de resolver problemas de natureza matemática. Ou até mesmo a criação de idiomas específicos do domínio especializados para o problema em questão.

Quando você conseguir criar um bom modelo de domínio, verá que o código da apresentação acaba sendo um shell fino na parte superior da camada de domínio.

Agora, o que ocorre com o aplicativo corporativo é que esse tipo de aplicativo (se você pode generalizar sobre aplicativos corporativos) geralmente envolve a modificação do estado das entidades cuja identidade é importante e a persistência das entidades modificadas em um banco de dados. Esse tipo de problema muito generalizado é IMHO muito melhor resolvido usando um modelo orientado a objetos do que um modelo funcional.

Isso não significa que existem áreas de um aplicativo corporativo que não poderiam ser melhor resolvidas por um paradigma funcional. Por exemplo, um módulo de análise de risco de um aplicativo bancário ou um módulo de planejamento de rota em um aplicativo de remessa. E talvez alguns aplicativos corporativos possam ser implementados totalmente usando um paradigma funcional.

Mas, em geral, acho que o paradigma orientado a objetos permite criar modelos de domínio mais úteis para a maioria dos aplicativos corporativos.

Editar

Devido a alguns votos positivos, minha atenção foi atraída para essa resposta - e desde que a escrevi, aprendi muito mais sobre o FP - e não tenho muita certeza se concordo mais com minha própria resposta. Algumas linguagens funcionais podem descrever muito bem casos de uso. Mas você precisa aprender uma mentalidade completamente diferente.

Sim pode. Pesquise um pouco no Google e você encontrará software real codificado em linguagens funcionais puras.

Quanto à sua pergunta sobre objetos de negócios, acho que seu problema real é com imutabilidade. Nesse caso, considere que você está retornando uma nova "Pessoa" toda vez que você a modificaria se estivesse usando uma linguagem imperativa.

Note que esta técnica também pode ser implementada usando linguagens imperativas!

Programação de Funções (FP), como Programação Orientada a Objetos (OOP), são paradigmas. Eles representam diferentes padrões ou abordagens para problemas de programação. Essas diferentes abordagens não impedem a capacidade de produzir software escalável, sustentável e extensível. Isso não quer dizer que as abordagens sejam equivalentes para todos os tipos de problemas; eles não são. Certos problemas se alinham melhor (ou pior) a paradigmas específicos, por exemplo, FP não seria minha primeira escolha para um programa que possui uma sequência dependente de operações com efeitos colaterais. No entanto, esses programas podem e foram escritos e bem escritos.

Sim, o FP pode ser usado em aplicativos corporativos. Clojure é um exemplo de linguagem FP com sucesso na empresa: http://cognitect.com/clojure#successstories

Representar estado pode ser um desafio no PF e mudar paradigmas para se ajustar ao FP pode ser um pouco complicado. Alguns idiomas FP impedem completamente os efeitos colaterais e o estado mutável. O Clojure permite, mas desencoraja ou isola esses paradigmas.

Em resumo, a representação do estado pode ser muito semelhante à OO. É uma modificação de estado que é muito diferente. Por exemplo, no estado FP, pode ser representado por listas e mapas. Uma lista de funcionários pode se parecer com:

[[name: "James Brown" address: "Barnwell, SC"]
 [name: "Elvis Presley" address: "Tupelo, MS"]]

Conheço duas maneiras de lidar com a modificação de estado no FP. Um é algo como programação reativa funcional. Nesse paradigma, todo estado é tratado apenas no nível mais alto ... por exemplo, uma visualização HTML do seu aplicativo possui um estado na visualização (como o nome da pessoa, endereço etc.). Agora, quando você clica em "atualizar nome", é chamada uma função que lida com tudo sobre uma atualização de nome, exceto a alteração do nome. Isso pode parecer estranho ... mas tenha paciência comigo. O nome alterado será retornado pela função e a exibição (ou armazenamento de dados persistente etc.) mostrará o novo nome. Ou, alternativamente, uma nova estrutura inteira com o nome atualizado será retornada. Então, o que a função faz? Ele valida o nome e retorna o novo nome, se for válido, um erro se não for, e possivelmente uma nova visualização ou link de navegação a seguir. Para algo mais complexo do que uma mudança de nome, pode fazer muito mais.

Portanto, para o FRP, o objeto retornado pela função é o novo estado e pode ser fornecido diretamente para a exibição ou o que estiver no nível alto. Em alguns casos, o FRP leva o estado inteiro para a função e recupera todo o estado.

Com esse paradigma, o contêiner ou estrutura precisa lidar com a atualização da exibição, banco de dados ou qualquer outra coisa que precise ser atualizada a partir do novo estado. Então você pode imaginar uma estrutura que desenha o aplicativo na tela. Quando um usuário clica em algo, as funções são invocadas e o novo estado é retornado. A estrutura atualiza a tela redesenhando tudo ou redesenhando partes da tela de maneira inteligente. Consulte http://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/

Clojure usa o segundo paradigma que me deparei e que é isolar as mudanças de estado, mas não necessariamente restringi-las ao nível mais alto. Com o Clojure, todo estado mutável deve ser "mantido" (a menos que você esteja usando objetos Java para estado) por um átomo, agente ou referência. A maneira como isso funciona é o objeto mantido ou apontado ou referenciado (como você deseja chamá-lo) pelo atom / agent / ref é imutável, mas o atom / agent / ref pode mudar para apontar para um novo objeto. Nesse caso, você usa métodos especiais no atom / agent / ref que dizem "atualize o objeto aqui fazendo isso e aquilo e reatribuindo o atom / agent / ref para um novo objeto".

Por que isso é benéfico, você pode perguntar? Como o objeto imutável referido por essas construções Clojure pode ser passado para uma função que faz alguma coisa e enquanto essa função está em execução, sua referência ao objeto é garantida para não mudar. Ou seja, o átomo / agente / ref não é passado para a função, mas o objeto imutável apontado por eles é passado. Átomos, agentes e refs têm propriedades especiais que lidam com atualizações e simultaneidade de maneiras seguras e parte do idioma. Veja http://clojure.org/state

Eu espero que isso ajude. Sugiro ler mais sobre o estado de Clojure e o FRP para entender melhor como os funcionários e pessoas podem ser representados no FP. No entanto, a representação real seria semelhante à programação orientada a objetos ... é a mutabilidade que é realmente diferente.