"Efeito colateral" e "funções puras" podem não ser o melhor nome
Eu sou uma nova programadora. Eu comecei a estudar há sete meses e desde o começo do meu aprendizado, que foi e é em JavaScript, a semente da programação funcional foi plantada no meu coração.
A minha experiência com o paradigma da programação orientada a objetos me deixou confusa e cansada. Foi sempre a mesma coisa: eu seguia a aula, acompanhava o projeto e entendia o código. Um mês depois eu lembrava vagamente do que eu tinha feito e, quando abria a aplicação, me perdia em pastas e arquivos, controllers, helpers, models, views, services… me sentia sobrecarregada com tanta informação e não conseguia achar o “código”. É como um labirinto! Um import que pega daqui, que aponta pra lá, que está instanciado acolá na outra pasta. Caso não tenha ficado claro, foi uma experiência péssima.
Já a minha esperiência com programação funcional foi muito mais agradável. Quando eu me deparei com o mesmo cenário do parágrafo anterior (revisitar uma aplicação antiga e tentar entendê-la), ao abrir o programa, era como ler uma receita de bolo. Existe uma função principal que lista os passos da receita, e várias outras funções que cuidam cada uma da sua parte. Tem uma função que mede ingredientes, uma que prepara a massa, uma que faz só o recheio, uma que faz a cobertura e é isso. A função de cobertura não se importa com o tipo ou tamanho de bolo, se tem ou não recheio, aliás, ela nem liga para o tipo de cobertura! Tudo o que ela faz é receber os ingredientes e devolver uma cobertura com o sabor dos ingredientes. E isso é tão fácil de entender! E se você se perder, é só voltar na função principal e achar o caminho de novo. Uh! Aí sim! Isso é um tipo de programação que me motiva!
A questão dos paradigmas é que eu nem sabia que eles existiam até o meu curso de front-end “naturalmente” caminhar para a programação orientada a objetos. Eu achei isso esquisito, porque quando o curso de JS começou, tudo era feito com funções. É assim que o aprendizado começa, imagino que porque é mais fácil desse jeito. E de repente tem uma ruptura na lógica e você é ensinado que o que faz sentido agora é modificar toda a sua estrutura de pensamento e adotar esse novo jeito que é “certo” para questões maiores e mais complexas. Como se esse fosse simplesmente o caminho natural das coisas. Pra mim nunca foi. Talvez seja porque eu sempre gostei de matemática, mas pensar em termos de funções é o que faz sentido pra mim. E nada do que eu vi me convenceu do contrário.
Foi assim que eu descobri sobre a existência de diferentes paradigmas, e assim que cheguei em um jeito diferente de programar, que usava funções como ferramenta principal. Um jeito que se chama programação funcional, e foi nesse grupo que eu encontrei a minha tribo. Nessa tribo eu ouvi de alguns palestrantes e em alguns podcasts que não existe um paradigma melhor que o outro em si mesmo, e que o melhor é o que resolve o seu problema. Bem, sobre isso eu tenho duas coisas para dizer. A primeira é que essa parece ser uma opinião absolutamente razoável e pragmática de se ter. Porém, eu acho difícil concordar. Para mim programação funcional é muito mais intuitiva e simples, e o que me vem à mente é aquela ideia de “trabalho duro não é a mesma coisa que trabalhar de maneira inteligente” e programação orientada a objetos parece desnecessariamente complexa. Mas, como eu tenho exatamente zero experiência no mundo real da programação, eu estou confortável em suspender julgamento até um outro momento. A segunda coisa é uma cutucada no “outro lado”, pelo menos o outro lado que eu tive contato. Eu precisei sair da curva e descobrir a programação funcional fora do meu curso para ouvir que não existe paradigma superior. E agora isso é uma proposição que eu estou levando em consideração. Mas e os meus colegas alunos que não saíram da curva? Eles sequer sabem que existem outros paradigmas. Vê o problema? Você não precisa ensinar que um é melhor que o outro quando você nem menciona que existe outro.
Enfim, agora que você conhece a minha história, vamos deixar a orientação a objetos de lado porque eu quero levar essa conversa para os termos da programação funcional e qual está sendo o meu problema com eles. Nós temos dois termos que eu tive e ainda tenho dificuldade de usar. São as funções puras e os efeitos colaterais.
Minha dificuldade inicial foi conseguir apontar uma função que tinha efeito colateral, porque efeito colateral é algo indesejado. Em paralelo, funções puras são o que nós mais queremos. Eu me vi o tempo todo refatorando e pensando em como ter mais funções puras, ficando até meio estressada com isso. Você pode pensar que tirando o estresse é isso mesmo que a gente quer: mais funções puras e menos efeitos colaterais. Mas vem comigo.
O que é uma coisa pura? O que nós associamos com pureza? Sem entrar em detalhes, são coisas boas. O que é não puro? O impuro é ruim. Você não quer beber, comer, usar ou tocar alguma coisa impura. O que é efeito colateral? Efeito colateral é algo que você não quer, mas pode acontecer. Nesses tempos de pandemia é ainda mais claro o que é o efeito colateral. Você toma uma vacina e pode ter dor de cabeça, inchaço no local da aplicação, dor no braço, febre e etc. E apesar do efeito colateral não ser por definição algo ruim, e o exemplo clássico disso é a descoberta do Viagra, é certamente algo que você não espera nem controla. Ou seja, ambos os termos apontam para mesma coisa: funções com efeitos colaterais são ruins. Mas elas são ruins? Bem… Não. Elas não são ruins.
Na conferência GOTO de 2018, o Russ Olsen deu uma palestra sobre programação funcional e o que ele falou sobre efeitos colaterais foi o que me motivou a escrever este artigo. O que ele disse foi que o nosso trabalho como desenvolvedores é fazer efeito colateral, porque essa é a única parte importante para o usuário. Ele não está tá nem aí para a implementação, ele quer saber se funciona e se é bom de usar. Para o consumidor, o efeito colateral é o efeito desejado. E isso, meninos e meninas, é exatamente o que eu penso.
Veja bem, eu não me oponho ao princípio da coisa e concordo que é interessante isolar e delimitar o efeito colateral. O problema é o termo. Porque acessar o mundo externo é uma ação deliberada. A interação com o DOM é proposital e controlada. Então por que cargas d’água nós nos referimos à isso como se fosse inesperado? E foi difícil apreender esse conceito, porque eu ficava procurando alguma coisa paralela que a função estivesse gerando que estava fora do meu controle, ou que eu não estivesse percebendo. E quando eu finalmente entendi, eu me senti meio idiota, tipo “É só isso?”. Mas eu acho que não sou o problema, o nome que é ruim mesmo.
Talvez você seja uma pessoa programadora experiente que já se acostumou com os termos, talvez você seja jovem na área e também sentiu essa dificuldade, talvez você não ligue tanto para termos. Mas eu acho que independente do nosso nível de conhecimento, abstração ou interesse, esse é um tópico que vale a pena ser discutido, e talvez quem sabe, repensado.