Engenheira de software & cientista da computação
Programming languages, crypto, web
Gêmeos ascendente em escorpião
Sometimes speaker, sometimes community
manager, always shitposter
Ana Luiza Portello Bastos
Slide 2
Slide 2 text
● Um pouco de história
● O que é o paradigma
● Jargões comuns
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
QUIZ
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
TURING MACHINE
Em 1936 o Allan Turing
formalizou um modelo
abstrato de um computador
chamado "Turing Machine"
Slide 8
Slide 8 text
TURING MACHINE
Memória estados e transição
Slide 9
Slide 9 text
TURING MACHINE
Em 1936 o Allan Turing
formalizou um modelo
abstrato de um computador
chamado "Turing Machine"
Slide 10
Slide 10 text
TURING MACHINE
- Alfabeto, Semantica
- Programming languagens são
equivalentes a uma turing machine!
Slide 11
Slide 11 text
CALCULO LAMBDA
O sistema formal do calculo lambda foi
definido nos anos 30 pelo Alonzo Church
para explorar a computabilidade com
definição de funções e recursão.
Slide 12
Slide 12 text
LAMBDA CALCULUS
λx . x + 1 (a)
(head) (body) (outra expressao)
expressão
A solução de um problema é feita por meio de funções,
usando uma implementação um conjunto de primitivas e
regras pra construir esses primitivas
Slide 13
Slide 13 text
A cabeça define uma função e seus parametros formais(x), e o corpo a
expressão (x + 1).
Função que recebe x a qual adiciona x a 1
λx . x + 1 (a)
(head) (body) (outra expressao)
expressão
Slide 14
Slide 14 text
CALCULO LAMBDA
1932 - "A set of postulates for the foundation
of logic"
1936 - untyped lambda calculus
1940 - typed lambda calculus
1960 - Passam a aplicar o sistema lógico em
linguagens de programação
Slide 15
Slide 15 text
(+ 1 2)
(defun mult2 (x) x * 2)
Slide 16
Slide 16 text
TURING MACHINE
1937 - Provou equivalencia ao
calculo lambda em termos de
computabilidade
"Tese de church-turing"
Slide 17
Slide 17 text
Mas até poucos anos atrás computadores não eram tão rapidos
quanto hoje em dia e tinham bem pouco poder de
processamento.
Pra isso era importante utilizar linguagens que possibilitassem
uma economia na memória e para isso linguagens imperativas
que lidavam bem com a memória e faziam tarefas de forma
procedural ficaram em alta.
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
SMALLTALK
Allan Kay pensou em uma
forma de tornar código
imperativo mais modular
“We were after the C++ programmers. We
managed to drag a lot of them about
halfway to Lisp.”
Guy Steele, co-author of the Java language specification
Slide 23
Slide 23 text
IMPERATIVA
Sequencia de instruções que
alteram o estado do programa a
medida que são executadas
Slide 24
Slide 24 text
IMPERATIVA
int total number1 number2;
number1 = 5;
number2 = 10;
total = number1 + number2
Slide 25
Slide 25 text
IMPERATIVA
Slide 26
Slide 26 text
OO
Classe cupcake
Instancias
Props: Ser fofinho
Slide 27
Slide 27 text
OO
Massa do cupcake tem um estado(self ou this)
Esse estado é MUTAVEL
E os metodos vão constantemente mudar esse estado
Existe uma ordem pra que tudo seja feito(É imperativo)
Slide 28
Slide 28 text
DECLARATIVAS
- Descreve o "o que" ao invés do "como"
- Descreve do "input" os valores do "output" ao invés de pensar
na manipulação de variaveis na memoria.
Slide 29
Slide 29 text
DECLARATIVA
Normalmente fazemos uma massa doce com proporcoes x de leite, farinha e açucar
Fermento faz a massa crescer
A massa cresce 30 por minutos ate ficar boa pra assar
O forno é o lugar em que assamos bolo
A forma ideal é diferente para se queremos bolo, cupcake ou pão
Por assar entendemos colocar a massa sob uma temperatura de 200c ou por 40
minutos no microondas.
Slide 30
Slide 30 text
FUNÇOES
- Código que pode ser executado mais de uma vez
- Relação entre input e output
Slide 31
Slide 31 text
FUNÇOES
- Você se lembra de aprender sobre f(x) na escola?
- O que é equação y = f(x)? f(x) = 2x^3 + 3
Slide 32
Slide 32 text
FUNÇOES
- Supondo que o valor de x é 2. Se você coloca em uma equação o
valor fica 11.
- 11 é o retorno da função f(2), que representaria o y na img
Slide 33
Slide 33 text
FUNCIONAL
Slide 34
Slide 34 text
OOP x FUNCIONAL
- Criar codigo claro
- Ser flexível ao crescimento do código
- Ser bug-free
Slide 35
Slide 35 text
OOP x FUNCIONAL
- Dados e comportamento são separados
- OOP muda estado enquanto fp faz os dados fluirem
- Um é declarativo outro imperativo
- Base teorica por trás
Slide 36
Slide 36 text
OOP x FUNCIONAL
Foco do programador Como executar tarefas (algoritmos) e
como controlar alterações no estado.
Informações que é desejada e que
transformações são necessárias.
Alterações de estado Importante. Inexistente.
Ordem de execução Importante. Baixa importância.
Controle de fluxo
primária
Loop, condições, e chamadas de função
(método).
Chamadas de função, incluindo a
recursão.
Unidade principal de
manipulação
Instâncias das classes ou estruturas. Funções como objetos de primeira
classe e coleções de dados.
https://docs.microsoft.com/pt-br/dotnet/standard/linq/functional-vs-imperative-programming
Slide 37
Slide 37 text
FUNCIONAL
Slide 38
Slide 38 text
FUNCIONAL
Slide 39
Slide 39 text
FUNCIONAL
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
JS
Pode ter
● Partial application
● Pipeline
● Pattern Matching
Tem
● HOF
● Funções anonimas
● Loops
declarativos(map,
filter, reduce,
flatmap)
Slide 42
Slide 42 text
No content
Slide 43
Slide 43 text
λx x*2
Slide 44
Slide 44 text
No content
Slide 45
Slide 45 text
Produtivo
Seguro
Slide 46
Slide 46 text
JS pode ser mais produtivo mas certamente não é tão
seguro quando falamos de mutabilidade de estado.
Slide 47
Slide 47 text
● Mil bibliotecas diferentes
● Atualizações melhorando a linguagem
● Padrões de codigo
● Já que as mutações não são seguras podemos
procurar aplicar padrões que garantem um código
mais bug free
SEEEE… tentassemos garantir um pouco de
predictabilidade da linguagem talvés podemos tornar o
código mais seguro...
Slide 53
Slide 53 text
https://medium.com/outsystems-engineering/programming-without-state-chaos-6b3dbbd58b7e
Se funções fossem
100% independente
não teriamos
patifarias escondidas.
Isso é similar ao que a gente vê
como funções matematicas, input
e um output.
Esse estilo chama-se
Slide 54
Slide 54 text
https://medium.com/outsystems-engineering/programming-without-state-chaos-6b3dbbd58b7e
- Mutações de qualquer varíavel ou objeto
- Logs
- I/O
- Banco de dados
- API
- Fazer trigger de algum processo
IDEPOTENCIA
Em funções puramente matematicas não existe a
possibilidade de chamar a mesma função com os
mesmos valores duas vezes e dar diferentes
resultados
Slide 57
Slide 57 text
No content
Slide 58
Slide 58 text
No content
Slide 59
Slide 59 text
No content
Slide 60
Slide 60 text
No content
Slide 61
Slide 61 text
No content
Slide 62
Slide 62 text
No content
Slide 63
Slide 63 text
PUREZA
● São Idepotentes
● Não tem side-efffects
Slide 64
Slide 64 text
PUREZA
Quando as funções são puras, ou seja, independentes de
estado ou do ambiente, não precisamos dar a mínima
importância para quando ou onde elas serão computadas.
- O dominio do que é estado e o que é logica
- Pequenas modificações tocam um estado espalhado
pela aplicação
- Em caso de algo falhar, ou concorrencia estamos
mais prunes a erros
Slide 85
Slide 85 text
No content
Slide 86
Slide 86 text
No content
Slide 87
Slide 87 text
CONTA
CLIENTE
TRANSACA
O
LIST
PONTOS
ENDERECO
TRANSACAO
TRANSACAO
TRANSACAO
Slide 88
Slide 88 text
No content
Slide 89
Slide 89 text
No content
Slide 90
Slide 90 text
No content
Slide 91
Slide 91 text
No content
Slide 92
Slide 92 text
IMUTABILIDADE
Slide 93
Slide 93 text
No content
Slide 94
Slide 94 text
No content
Slide 95
Slide 95 text
No content
Slide 96
Slide 96 text
● O estado aumenta a complexidade e torna dificil de "reason about"
problemas locais.
● A solução é isolar o estado e aumentar o codigo puro
● Se você precisa de umestado local, encapsule-o em funções puras.
● Side Effects são necessarios, mas podem ficar isolados e abstraidos
● Testar funções puras é só questão de checar um valor de retorno!
Slide 97
Slide 97 text
MOTIVACAO
● Mantenabilidade de código
● Menos bugs
● Testar se torna uma tarefa facil!
● Muito mais facil lidar com estado!
● Front end: estado imutavel, declaratividade
● Lidar com o caos que é o estado
Slide 98
Slide 98 text
NA PRATICA
As vezes você vai precisar sacrificar pureza por performance,
limitações da linguagem ou por simplicidade.
Nesse caso o ideal é tentar encapsular o estado ou tentar de alguma
forma isolar o efeito colateral.
NA PRATICA
Se em programação funcional tudo são funções como lidamos
com estas funções?
A ideia é que cada uma delas tenha uma unica responsabilidade
dentro de um contexto
Slide 101
Slide 101 text
QUIZ RESULTS
Slide 102
Slide 102 text
No content
Slide 103
Slide 103 text
● Em linguagens procedurais nossas computações
envolvem nosso código separado em modulos
operando em dados.
● Já em linguagens orientadas a objetos encapsulamos
nosso código e dados para que eles interajam entre si
por meio de mensagens.
Slide 104
Slide 104 text
No content
Slide 105
Slide 105 text
No content
Slide 106
Slide 106 text
No content
Slide 107
Slide 107 text
Independentes
Puras
Dados fluem nelas
Slide 108
Slide 108 text
No content
Slide 109
Slide 109 text
No content
Slide 110
Slide 110 text
COMPOSICAO
FUNCAO
INPUT OUTPUT
Slide 111
Slide 111 text
FUNCAO1
INPUT OUTPUT FUNCAO2 OUTPUT
Slide 112
Slide 112 text
COMPOSICAO
COMP
(FN1 + FN2)
INPUT OUTPUT
Slide 113
Slide 113 text
COMPOSICAO
Aluno foi aprovado?
● Fazer a média dos trabalhos e provas
● Incrementa 1 se o aluno tem nota de participação
● Se for maior que 6 está provado
Slide 114
Slide 114 text
COMPOSICAO
Lista de notas => Aplicar a média => Checa se deve incrementar 1 => Passou?
Slide 115
Slide 115 text
COMPOSICAO
gte(6)(inc(mean(list)))
Slide 116
Slide 116 text
COMPOSICAO
isAprovado(list)
IsAprovado = list => gte(6)(inc(mean(list)))
Slide 117
Slide 117 text
FUNÇOES
f(x) = x + 1
g(x) = x * 2
f . g
Slide 118
Slide 118 text
PIPE
Pipeline em ciência da computação é todo tipo de
processamento de dados conectado em série em que a saída
de um elemento é a entrada do proximo similar ao pipe do
UNIX.
Slide 119
Slide 119 text
PIPE
list
=> mean
=> inc
=> gte(6)
Slide 120
Slide 120 text
Resolver com PIPE!
Aluno foi aprovado?
● Fazer a média dos trabalhos e provas
● Incrementa 1 se o aluno tem nota de participação
● Se for maior que 6 está provado
Slide 121
Slide 121 text
PIPE
Slide 122
Slide 122 text
PIPE
Slide 123
Slide 123 text
PIPE
Slide 124
Slide 124 text
condition ? expr1 : expr2
Slide 125
Slide 125 text
No content
Slide 126
Slide 126 text
No content
Slide 127
Slide 127 text
No content
Slide 128
Slide 128 text
No content
Slide 129
Slide 129 text
No content
Slide 130
Slide 130 text
HOF
A ideia de que funções são entidades primarias. Elas
são tratadas como valores e usados como dados!
- Passadas como paramentros
- Passadas como resposta de uma função
Slide 131
Slide 131 text
HOF
const doubleSum = (a, b) => (a + b) * 2;
Slide 132
Slide 132 text
HOF
Agora a função subtrai os valores e faz
o double
const doubleSum = (a, b) => (a - b) * 2;
Slide 133
Slide 133 text
Essas funções são parecidas, a unica diferença é o
operador.
Se podemos tratar funções como valores e
passa-los como argumentos, pq não passar a
operação por argumento?
- Ao invés de Loops, iterações declarativas.
- Ao invés de design patterns,
componentização
- Novos fluxos de trabalho: pipelines, pattern
matching, partial application, laziness,
currying.
Slide 149
Slide 149 text
No content
Slide 150
Slide 150 text
No content
Slide 151
Slide 151 text
CREDITS: This presentation template was created by
Slidesgo, including icons by Flaticon and infographics &
images by Freepik
Perguntas?
hello@anabastos.me
anabastos.dev
Contact
@naluhh
anabastos