258 - A SUPERIORIDADE da PROGRAMAÇÃO FUNCIONAL 😱😱😱 | theWiseDev Functional 

Estou aprendendo com PHP, é bem útil.

Valeu, Pedro! Venha para o lado funcional da força! 😅

Na minha opinião a linguagem deve apoiar o uso de polimorfismo E encorajar fortemente a imutabilidade. O primeiro ponto é coberto por essas linguagens que você indicou mas o segundo não.

Tô curtindo clojure, mas acho legal a abordagem híbrido como o do kotlin, confesso que ainda prefiro mais o kotlin, mas deve ser pq só tô no começo do namoro com clojure

@@joaogabrielbracaioli Boa, Braca! :)

Massa...

Sim. O Feldman até comenta que tem programado em Rust e que há alguns recursos para prevenir mutação.

O livro que eu pedi para o Uncle Bob escrever será sobre isso. 😄

@@otaviolemos estou ansioso pra ler esse livro :)

Opa, obrigado! Quem são os professores? Você não falou o nome deles nem do grupo... :)

Opa, já achei aqui: ufabc hal :)

Legal! Eu acho que o youtube bloqueia links, então não publiquei. Lá no Discord o nome do grupo é "Programação Funcional". Tenho certeza que vai gostar!

vi uma parte faz um tempo e realmente é increvel a didatica do professor

@@CalangoBit Não consegui encontrar o servidor no Discord.

Sim, será à noite!

Structure and Interpretation of Computer Programs ou algum mais específico de linguagem. Eu tô indo direto no Clojure for the Brave and True (ensina mais a linguagem mesmo) junto com Clojure Applied (ensina como fazer software com Clojure).

Por exemplo, se implementássemos um scanner que retorna os elementos sob demanda, precisaríamos de uma forma de alterar o index atual que estamos. Como isso seria possível em uma função pura?

Uma coisa que eu acho lindo dentro da programação funcional é o tratamento de erros. O Either com Left e Right é tão bom que existem pacotes em outras linguagens para simular esses comportamentos, como o dartz no Dart e o fp-ts no Typescript. Também acho bem legal a pegada do Go de permitir que a função tenha múltiplo retorno pra erro, e se o erro é diferente de nulo, o tratamento é obrigatório

Opa, ainda não sou especialista no tema, mas posso tentar responder. Sim: a ideia é manipular estruturas de dados mais simples, não há 'objetos' com dados e comportamentos conectados. Na questão da tipagem, depende da linguagem, como nas imperativas temos linguagens estaticamente tipadas (como é o caso do F#) e dinamicamente tipadas (como é o caso do Clojure). No caso da passagem de parâmetros acho que você pode passar uma referência mas no fundo tanto faz porque você não pode alterar o dado de qualquer maneira (valor ou referência, tanto faz).

No Clojure há 'protocols' que, pelo que entendi, são bem semelhantes às interfaces. O F# parece ter interfaces. Acho que aí depende muito da linguagem.

A minha experiência dentro do que eu estudei foi muito em cima de linguagens funcionais estaticamente tipadas (embora eu não tenha de fato programado nelas, eu só estudei os conceitos e apliquei usando TS), então em closure as abstrações provavelmente seriam diferentes. Mas algo que eu venho achando em comum quando se estuda design de programas funcionais é que geralmente as coisas acabam naturalmente terminando em alguma forma de arquitetura limpa (embora geralmente acabe ficando bem próximo da Onion architecture). Você modela o core do sistema de forma totalmente pura, e empurra o código impuro para as bordas. Num geral você não tem objetos mesmo então você vai mexer com alguma coisa parecida com as structs, mas geralmente as linguagens definem bem as estruturas de dados básicas que ela te fornecem. Mas não é algo tão pobre quanto em linguagens imperativas, pelo menos nas fortemente tipadas, você usa um sistema de tipos algébricos para descrever as coisas (seria o & e o | do TS), além de depender bastante de generics (se pensar no TS você consegue imaginar melhor, o sistema de tipos dele cobre bastante coisas em comum com sistemas de tipos usados em linguagens funcionais). Uma abordagem que eu acho muito legal é a do cara do site F# for fun and profit onde ele diz que é uma boa modelar o seu sistema a partir dos tipos e depois pensar nas suas implementações, então na maior parte do tempo você pensa em interfaces/types e só lá no final você pensa na implementação, o que ajuda a focar bem no domínio que você está modelando. A abstração em linguagens funcionais é um pouco diferente das linguagens OOP, ao invés da gente utilizar objetos, eu vejo que se usam muito estruturas algébricas (seriam aquelas coisas de Monads, Functors e etc) e um conceito chamado de Type classes para implementar elas, eu ainda estou estudando esse assunto então não sei explicar bem o que é uma type class, mas pelo que eu vi num livro sobre paradigmas de programação, elas são uma forma de abstração assim como objetos, que seria o que habilita o uso de polimorfismo em linguagens funcionais.

Pois é: no final eu acho que a única saída é ir para uma linguagem puramente funcional para se ter os benefícios da imutabilidade.