Modelos mentais ou metáforas do mundo real para programação funcional

Alguém tem um bom modelo mental ou metáfora para programação funcional que faça referência a algo no mundo real?

A programação orientada a objetos intuitivamente faz sentido para mim. Existem coisas que têm propriedades e, às vezes, elas também podem fazer coisas ou executar cálculos em suas propriedades (métodos). (Ex: Carro, Forma, Gato).

Não agüento programação funcional e não estou interessado em um debate sobre as virtudes dos dois. Eu só preciso de uma metáfora ou modelo mental para trabalhar como tenho com a programação orientada a objetos.

Quais são alguns bons modelos mentais ou metáforas do mundo real para a programação em um paradigma funcional? Há algo sobre funções compostas de funções que processam funções que deixam alguém sem um lugar firme para se posicionar e cogitar.

A programação funcional consiste em colar funções menores para alcançar seus resultados. Um modelo mental decente (para mim, pelo menos) é uma linha de montagem. Cada função que é composta é mais uma etapa no processo de montagem. Considere esta função aqui:

smallest  = head . sort

No Haskell, essa função retornará o menor elemento de uma lista. A linha de montagem classifica primeiro a entrada e, em seguida, retorna o primeiro elemento (supondo que seja classificada da menor para a maior). Se quisermos obter apenas o menor valor par, podemos alterar a linha de montagem para ter a seguinte aparência:

smallestEven = head . sort . filter even

É apenas mais um passo na correia transportadora.

Em poucas palavras, as funções descrevem apenas as etapas adotadas para converter a entrada bruta (as partes) na mercadoria processada (a saída).

Alguém tem um bom modelo mental para programação funcional?

Matemática.A programação funcional é inspirada e modelada em matemática. As funções matemáticas não têm estado, não têm efeitos colaterais, etc., e assim é com o FP. Se você pensar em FP em termos de funções matemáticas, em vez de usar uma abordagem "como faço isso para isso" no estilo OO, você estará em boa forma. Se você tentar trazer sensibilidades de OO para FP, no entanto, estará nadando contra a corrente.

Que tal um flip book ?

Em um flip book, cada página representa o mundo como ele existe no momento. Em nosso programa, o mundo é representado como uma estrutura de dados composta (por exemplo, temos uma banana que está na mão de um gorila que está em uma árvore que está em uma floresta). Cada página subsequente avança a história modificando ligeiramente a representação anterior. No FP, as estruturas de dados persistentes foram projetadas para reutilizar eficientemente as estruturas anteriores, de modo que uma mudança forneça apenas um delta e não uma renderização completamente nova.

O que pode não ser óbvio é que uma página do nosso flip book também representaria intangíveis. Por exemplo, se o gorila deixa cair a banana, podemos começar a aplicar os efeitos da gravidade em sua decente e aceleração em direção ao solo da selva. Para acomodar isso, atribuímos atributos como velocidade e trajetória à nossa banana.

Em nosso programa, haveria uma função que aceita uma página de flip-book (também conhecida como o estado do mundo) como argumento e gera uma nova página . Dessa maneira, nossa história é contada sem jamais alterar o estado dos objetos existentes. Simplesmente substituímos cada página por uma mais nova, usando o que é efetivamente um cálculo.

Relacionamentos.

Amigo: Dadas duas pessoas, um relacionamento de amigo segue estas leis gerais

1. Tenha boa vontade um com o outro
2. Acha que os outros são amigos deles (então as leis devem ser cumpridas pelos dois membros nesse relacionamento)
3. Gosta de passar tempo juntos

Monóide: dados vários itens e uma função que pega 2 dos itens e retorna 1, um relacionamento monoidal segue estas leis gerais

1. Há um desses itens (apenas um, chamado identidade) que passou para a função com qualquer outro item garantirá que a função sempre retorne o outro item (0 + 1 = 1, portanto, 0 é a identidade quando os itens são números e o função é adição)
2. A função não pode operar ou devolver itens que não estão no conjunto com uma relação monoidal com
3. A função é associativa e pode ser usada com os itens de maneira um tanto independente da ordem, ou seja, a * (b * c) = (a * b) * c que diz que você pode multiplicar a pelo resultado de b * c ou c pelo resultado de a * be o resultado será o mesmo que você fizer primeiro.

A programação funcional é sobre generalizações, o amigo é um relacionamento muito geral que pode ser visto em vários cenários, mas em todos os vários formatos geralmente segue as leis acima.

Reconhecendo as leis que governam os relacionamentos entre as coisas, você pode criar implementações gerais que funcionam em qualquer formato de coisas que possua esse tipo de relacionamento. Na programação funcional, você tenta identificar os relacionamentos entre as coisas, para que elas possam ser classificadas e tratadas em geral.

Você quer uma metáfora do mundo real? Veja como as coisas estão relacionadas e tente identificar leis gerais (como aplicável a vários cenários em que outras coisas que não as leis podem variar). Existe um relacionamento entre um registrador e um comprador em uma loja, ele possui algumas leis gerais, um software foi desenvolvido para facilitar os objetivos das pessoas nesse relacionamento geral na forma de sistemas POS. Da mesma forma, quando você começa a ver essas leis gerais determinando como as coisas estão relacionadas, pode começar a confiar nas leis desses relacionamentos ao escrever seu software, em vez dos detalhes específicos de uma instância de um relacionamento.

Tudo é um valor, e você aplica funções aos valores (que podem ser funções) para produzir novos valores, de preferência sem produzir efeitos colaterais.

O principal a perceber sobre a programação funcional é que tudo é um valor - até o próprio código é 'valores'.

O melhor exemplo de um ambiente de programação funcional simples é o da ferramenta de negócios favorita de todos - a planilha. Cada célula da planilha é de dados ou o resultado de uma função. Além disso, essa função não pode ser desativada e modificar outra célula.

Quando se move para uma linguagem funcional, em vez de uma grade cartesiana de A1e B42, as funções têm nomes. Isso é tudo o que realmente é.

Existem outros aspectos que podem ser adicionados além disso ... mas essa é a programação funcional em sua essência. Não é preciso se preocupar com a estrutura das listas ou o agrupamento de coisas. A programação funcional é sobre passar um valor para uma função e recuperar um valor sem ter que mexer em outro lugar na memória.

É isso aí. A programação funcional é uma planilha com nomes e não uma grade.

Você pode pensar em programação funcional como sobre comportamentos . Um programa é uma descrição do comportamento que você deseja que o computador decida. As funções são a unidade básica de comportamento, e a composição das funções é uma maneira de criar comportamentos maiores a partir dos menores.

No OOP, um objeto de código deve ser o estado de um objeto no domínio do problema; muda ao longo do tempo para refletir as alterações nesse objeto de domínio. No FP, um valor representa o estado de um objeto de domínio; isso nunca muda, você simplesmente cria valores diferentes para representar estados diferentes.

Acho o modelo funcional um pouco mais honesto sobre o que os computadores estão realmente fazendo - representando. Afinal, eu não posso simplesmente conjurar um new Tesla()nada. :)

As frases são mais funcionais do que orientadas a objetos, supondo que você as descreva mais ou menos como as seguintes ...

The brown cow is in the meadow across the deep river.

Então, precisamos encontrar as frases principais e o resto:

The cow (brown)
the meadow (across)
the river (deep)

Numa única tentativa:

sentence: The cow ((the meadow (the river (deep)) (across)) brown)

Árvore de análise:

|                     sentence
|                      /         
|                  The cow
|                 /       \
|            the meadow   brown
|            /         \
|      the river      across
|              \
|              deep

A parcimônia infecta o pensamento funcional;

Tiremos o chapéu para Gottlieb Frege, década de 1890, Alan Turing (entschiedungsprobleme), década de 1930, Noam Chomsky (década de 1960).