isso depende, se a pessoa faz um map e apos um filter, mais facil usar somente um for, vai ser mais rapido ja que so vai itinerar 1x, mas dependendo mt sai quase a msm coisa kkkkk
@@kevingood10 exatamente isso. Nesse caso talvez seja mais semântico o uso de um for puro do que uma dessas funções de alta ordem. Mas ainda depende mto do caso, pode ser q fique ainda mais claro o q esta sendo feito se for dividido nas duas funções. Tudo vai depender de como os devs envolvidos interpretam o código
4 месяца назад+3
Na real, toda linguagem é um conjunto de funções estéticas, que no fim é compilado em códigos simples onde nem "for" existe. A maioria dos compiladores traduzem no "goto" e no comparador lógico. Mas a diferença de programar no paradigma funcional para imperativo é absurda. Faz a leitura muito difícil para quem não a domina. Enquanto um cara que domina uma linguagem imperativa, com OO, geralmente vai entender a maioria dos códigos, independente da linguagem.
Sobre o `reduce` não ser built-in (sua fala em 7:38), na verdade por existir na biblioteca `functools` é considerado built-in (muitas pessoas confundem com a biblioteca `builtins` ou o próprio `__builtins__`), e uma curiosidade é que na versão 2 do Python o `reduce` não precisava ser importado, a decisão de movê-lo para uma biblioteca (que aconteceu na transição para a versão 3) foi extremamente contraditória: "ninguém usa".
Antes de tudo, parabéns pelo vídeo, excelente conteúdo!!! Na verdade, a gente pode colocar o Python no meio, junto com JS: apesar da comunidade Python usar o for de modo bem constante, quem é mais avançado usa muito List Compreention e lambda, que são abordagens mais funcionais. Eu mesmo, tenho usado mais essa abordagem pq deixa o código muito mais conciso e rápido. Valeu meu caro!!!!
Acho essas funções muito interessantes, uso elas quando estou com preguiça nos meus projetos de estudo. Porém, eu acho que o método de iteração ou recursão, na maioria das vezes, acaba sendo menos complexo em termos de bigO. Excelente Vídeo!
no js também temos o foreach, que intera em cada elemento da lista, nessa interação a referência passada é exatamente do item na lista, então se modificarmos o valor da interação, será modificado o valor no array original.
Creio que o exemplo dado de map em python tenha sido ruim, algumas dicas: A questão é que a galera usa errado o map em vários casos, o exemplo de map no vídeo é ruim (mas de forma didática serve) pra Python, já que o correto nesse caso seria utilizar um list comprehension. Use cases para map: Você precisa de um iterator para evitar a criação de uma lista grande na memória. Você já tem uma função definida para aplicar. Use cases para list comprehension: Você deseja uma maneira concisa e legível de expressar a lógica de transformação/filtro/aplicar função. Lidar com transformações complexas onde a criação de uma função separada é questionável (só irá usa-lá uma vez, por exemplo).
O conceito do "reduce" é mais complexo do que reduzir todos os números para um só, tem mais a ver com modificar "todos os itens" para "outra estrutura de dados" mutando um acumulador (não fazer copias na memória no processo). Ótimo video!
Java aderiu super ao paeadigma funcional, tem tudo do lado esquerdo, map reduce filter foreach, oneach, eu codei java por 5 anos e não lembro a ultima vez que escrevi um for em java
Maneiro o conteúdo. De fato concordo que substituir o for por qualquer coisa mais legível é o caminho certo a seguir, só não sei se eu travaria uma PR por causa disso. Depende do caso, claro.
@@leandromf31 tem casos que não faz muita diferença trocar o for por outro loop, mas tem casos que faz muita diferença. Sigo o princípio de que a gente deve escrever código pros outros. Então tento fazer o mais legível possível. Não vou impor isso ao pé da letra em PR alheia, mas se tiver grotesco tem que pedir pra refatorar
No typescript eu uso o filter, map, reduce, porém uma coisa que eu raramente uso é um forEach, prefiro um for of, for in, ou um classico for i, pra mim fica mais fácil ler o codigo com um forof/forin/fori do que com um forEach
se eu não me engano no JS a perfomance desses métodos de array é menor que implementar o for. Enfim, é uma forma de diminuir a leitura, mas muitos devs se confundem com o que tá acontecendo no código se ele não tem a prévia do que esses métodos fazem, e tem o lance de ter que trabalhar com Promise.All no retorno desse métodos caso tenha que trabalhar com codigo assincrono. Tem os prós e contras, mas cada caso é um caso. Particularmente eu gosto de utlizar porquê diminui código e pra mim, ajuda na leitura.
apesar de ser um pouco mais dificil de entender, acho q seria valido ter feito as funções para implementar na mão com recursividade, assim ficava mais claro que da para não usar o for.
SENIOR é o cara q consegue entender qualquer código, principalmente Assembly. E quanto mais construo meus algorítimos usando o básico, menos problemas de deprecated tenho.
Do zen do python: Explicito é melhor que implicito. (caso não conheça, execute "import this" e leia) Em outras palabras, um for loop é mais "legivel"/"compreensivel" que o reduce(), o mesmo vale para "compreensões de lista". Você jovem dev, não vá no hype desses papinho de "eu não uso isso, eu não uso aquilo", lembre-se código bom é código simples. A "beleza" de um código é inversamente proporcional a sua complexidade.
@@user-db2uj9vc7s eu suspeito que não. o hype do OO aconteceu porque as pessoas tavam cansadas de se bater com C, Pascal e Fortran. com o tempo se percebeu que OO não é tão bom assim e que gera inúmeros problemas de manutenção, escalabilidade, performance, representação de dados e organização de código. o paradigma funcional (de verdade, não o que o JS faz) é perfeitamente reutilizável porque as funções são todas puras. não existem bugs tipo null reference ou bobagem desse tipo. é uma pureza matemática que OO nunca teve, OO foi baseado em achismos
Dev senior de verdade NÃO fala "não pode usar else, não pode usar for, tem que usar xpto...". Tudo tem sua utilidade e momentos, igual design patterns. Um laço for por exemplo, será mais performático que um .sum ou .reduce dado o custo da chamada de função, é o mesmo caso da recursividade, código interativo é mais rápido. Agora tem que ponderar com relação a legibilidade, eu uso muito .map e .find e . filter do js, mas não uso .reduce ou .foreach. O pessoal do anti "else" sempre puxa pros casos mais absurdos onde o código tem um zilhão de if aninhado e já teria que ser reescrito igual (se possível, pois existem situações raras que não vale a pena ou dá).
Depende, se vc estiver usando js, os array methods, como o map, ele funciona de forma concorrente, é mais rápido, mas pode ter problema de concorrência, por exemplo em um banco de dados, retornando erro de relacionamento errado
dá pra usar reduce pra soma dos elementos do array, mas o reduce é de uso super geral, você pode usar sempre quando precisar passar por todos os elementos do array e, com base neles, reduzir o array a algum outro valor tem que entender qual o papel do "acumulador" e do "valor inicial" pra tentar entender melhor os casos de uso
@@GutoGalego Você sabe que o artigo que você mandou está justamente indo de encontro o que o Heraldo falou ali em cima né? "Both for and for..of are 3.5 times faster than reduce. However, the loops are much more verbose"
Quando eu vejo o pessoal falando "estou aprendendo demais com os seus videos" acho que evidencia o quão baixo é o nivel de um programador médio, mostrando que esse papo de que o mercado está impossivel é só um monte de iniciante ou pessoa que não sabe programar de maneira efetiva tacando a culpa em qualquer coisa que não seja a si própria. O jeito que ele traz os videos são muito bons, mesmo eu discordando de muita coisa, tomara que ele traga conceitos ou ideias de niveis minimamente dificeis. Eu ainda prefiro muito mais esse cara do que um youtuber de fofoca.
Veja, o problema da produção de conteúdo é que quanto mais "difícil" e complexo é o teu conteúdo menos gente vai ter pra consumir ele. Acho q o papel dele tá sendo bem maneiro, apresentando soluções de senior pra qm é mais newbie
Ou seja ..... você "terceirizou"a criação do FOR .... trocou um FOR feito por você, pelo FOR feito por um programador MAIS EXPERIENTE .... perfeito ....
Se eu entendi bem tua pergunta, aí você pode usar combinações de map, filter e reduce no mesmo comando! Mesmo porque essas três formas aceitam funções como parâmetro inicial, e a função que você vai passar pode influenciar nos itens da array!
@@Zeuszsz, acho que o que ele quer é uma espécie de combinação de map e filter, como por exemplo só fazer algo no array se esse array (ou list no caso do Python) tiver a característica x. Por exemplo, só multiplicar por dois os itens da lista que forem ímpares.
Nao muda nada, visualmente um loop é muito mais fácil de entender, não muda nada na velocidade de percepção do usuário final. Esses vídeos de faca isso e não aquilo é só baboseira
Наука
Alternativas pra não usar for
Alternativas: for
A mudança é meramente visual, visto que por debaixo dos panos irá ser feito um for
Exato. Mas tbm tem a questao de melhorar a legibilidade do código, deixando explicito o que aquele "for" faz. Além de aplicar o Dont Repeat Yourself
isso depende, se a pessoa faz um map e apos um filter, mais facil usar somente um for, vai ser mais rapido ja que so vai itinerar 1x, mas dependendo mt sai quase a msm coisa kkkkk
@@kevingood10 exatamente isso. Nesse caso talvez seja mais semântico o uso de um for puro do que uma dessas funções de alta ordem. Mas ainda depende mto do caso, pode ser q fique ainda mais claro o q esta sendo feito se for dividido nas duas funções. Tudo vai depender de como os devs envolvidos interpretam o código
Na real, toda linguagem é um conjunto de funções estéticas, que no fim é compilado em códigos simples onde nem "for" existe. A maioria dos compiladores traduzem no "goto" e no comparador lógico.
Mas a diferença de programar no paradigma funcional para imperativo é absurda.
Faz a leitura muito difícil para quem não a domina.
Enquanto um cara que domina uma linguagem imperativa, com OO, geralmente vai entender a maioria dos códigos, independente da linguagem.
@ Descendo para o nível de máquina, existe sim, só não se chama "for" e sim "loop" do x86.
Melhor canal, enquanto to aqui nas calls desnecessárias do dia a dia to aprendendo demais contigo! Brabo demais kkkk
Nada é mais rapido, mais explicito e legível do que um loop for!
Sobre o `reduce` não ser built-in (sua fala em 7:38), na verdade por existir na biblioteca `functools` é considerado built-in (muitas pessoas confundem com a biblioteca `builtins` ou o próprio `__builtins__`), e uma curiosidade é que na versão 2 do Python o `reduce` não precisava ser importado, a decisão de movê-lo para uma biblioteca (que aconteceu na transição para a versão 3) foi extremamente contraditória: "ninguém usa".
Dizer que reduce é built-in por estar em functools é incorreta. Ela não é built-in no sentido tradicional, pois precisa ser importada
didática excelente!
Que vídeo incrível! Parabéns!
Antes de tudo, parabéns pelo vídeo, excelente conteúdo!!! Na verdade, a gente pode colocar o Python no meio, junto com JS: apesar da comunidade Python usar o for de modo bem constante, quem é mais avançado usa muito List Compreention e lambda, que são abordagens mais funcionais. Eu mesmo, tenho usado mais essa abordagem pq deixa o código muito mais conciso e rápido. Valeu meu caro!!!!
golang que é bom, só podemos usar for loop e é mais do que o suficiente para 100% dos casos e nunca senti falta de ter algum syntax sugar
Pois é… eu com meu for faço tudo sem problemas, não sei pra que esse tanto de frescura…
me lembro da época que eu ficava pensando "filter ou eu faço um while com if" (eram casos de não reutilização ta)
grandes questões da computação.
Não passava perto do reduce tem algo tempo já... Acabei de perceber o tanto de linha desperdiçada nos meus dataframes, em vez de usar o reduce.
MAP [func(i) for i in list]
FILTER [i for i in list if func(i)]
tutorial acima de como deixar seu código não "pythonico", "explicito é melhor que implícito"
@@ABarros548e isso é lindo
Estou desconfiando que essa saga está em Loop.
Seu canal é muito bom!
Clojure loop sao funções recursivas com otimização de tail head
Acho essas funções muito interessantes, uso elas quando estou com preguiça nos meus projetos de estudo. Porém, eu acho que o método de iteração ou recursão, na maioria das vezes, acaba sendo menos complexo em termos de bigO. Excelente Vídeo!
no js também temos o foreach, que intera em cada elemento da lista, nessa interação a referência passada é exatamente do item na lista, então se modificarmos o valor da interação, será modificado o valor no array original.
Creio que o exemplo dado de map em python tenha sido ruim, algumas dicas:
A questão é que a galera usa errado o map em vários casos, o exemplo de map no vídeo é ruim (mas de forma didática serve) pra Python, já que o correto nesse caso seria utilizar um list comprehension.
Use cases para map:
Você precisa de um iterator para evitar a criação de uma lista grande na memória.
Você já tem uma função definida para aplicar.
Use cases para list comprehension:
Você deseja uma maneira concisa e legível de expressar a lógica de transformação/filtro/aplicar função.
Lidar com transformações complexas onde a criação de uma função separada é questionável (só irá usa-lá uma vez, por exemplo).
O conceito do "reduce" é mais complexo do que reduzir todos os números para um só, tem mais a ver com modificar "todos os itens" para "outra estrutura de dados" mutando um acumulador (não fazer copias na memória no processo).
Ótimo video!
Reduce é tenso demais de masterizar
@@danielhorodenko8587 é muito simples quando percebes o control flow de modificar o acumulador
eu uso muito o reduce (aggregate) no c#
Ok, seus vídeos são muito bons.
Java aderiu super ao paeadigma funcional, tem tudo do lado esquerdo, map reduce filter foreach, oneach, eu codei java por 5 anos e não lembro a ultima vez que escrevi um for em java
O mais legal do reduce é que só com ele vc consegue fazer as outras funções todas que vc mostrou aí
Eu odeio código declarativo
Decorar uma caralhada de funcão q mudam dependendo da linguagem é um saco, prefiro aprender o algoritmo usar um loop
E a distinção não é funcional/imperativo
É imperativo/declarativo e funcional/procedimental/orientada a objetos
Maneiro o conteúdo. De fato concordo que substituir o for por qualquer coisa mais legível é o caminho certo a seguir, só não sei se eu travaria uma PR por causa disso. Depende do caso, claro.
Queria entende como um dev não acha o for legível… Muito mais simples de usar, sem frescuras, no pelo.
@@leandromf31 tem casos que não faz muita diferença trocar o for por outro loop, mas tem casos que faz muita diferença.
Sigo o princípio de que a gente deve escrever código pros outros. Então tento fazer o mais legível possível. Não vou impor isso ao pé da letra em PR alheia, mas se tiver grotesco tem que pedir pra refatorar
Muito bom
No typescript eu uso o filter, map, reduce, porém uma coisa que eu raramente uso é um forEach, prefiro um for of, for in, ou um classico for i, pra mim fica mais fácil ler o codigo com um forof/forin/fori do que com um forEach
No pyhton é tentador sempre usar da bala de prata list comprehension
Acho que nem é "alternativa pra não usar o for", mas sim "alternativa pra não reinventar a roda"
se eu não me engano no JS a perfomance desses métodos de array é menor que implementar o for. Enfim, é uma forma de diminuir a leitura, mas muitos devs se confundem com o que tá acontecendo no código se ele não tem a prévia do que esses métodos fazem, e tem o lance de ter que trabalhar com Promise.All no retorno desse métodos caso tenha que trabalhar com codigo assincrono. Tem os prós e contras, mas cada caso é um caso. Particularmente eu gosto de utlizar porquê diminui código e pra mim, ajuda na leitura.
apesar de ser um pouco mais dificil de entender, acho q seria valido ter feito as funções para implementar na mão com recursividade, assim ficava mais claro que da para não usar o for.
SENIOR é o cara q consegue entender qualquer código, principalmente Assembly. E quanto mais construo meus algorítimos usando o básico, menos problemas de deprecated tenho.
entao fodeu, pq n manjo nada de assembly e nao tenho curiosidade de implementar algo em assembly (apesar de ja ter estudado)
@@kevingood10 mano se vc tá conseguindo faturar uma grana o resto é bobagem. 😁👍🏽
@@Judenilson isso é vdd kkk
eu como desenvolvedor go nem me preocupo muito com isso
Essa implementação do reduce poderia ser bem otimizada, melhorando esse if / else por que sabemos que só vai entrar no if uma única vez.
exatamente
Ou seja, se eu ver alguém falando pra nao usar for, eu vou mandar ele calar a boca
Cara... Map reduce e esses paradigmas funcionais são muito mais antigos que o golang. Javascript por exemplo usa map reduce ha bastante tempo
em um fórum um usário perguntou "E como uso (map) isso em golang" - O Rob Pike falou "Você sabe usar o for?" 😂😂😂😂😂
você tá dizendo pra evitar o for mesmo que ele seja a melhor opção? porque essas 4 alternativas possuem cada uma o seu caso de uso tal como o for
Do zen do python: Explicito é melhor que implicito. (caso não conheça, execute "import this" e leia)
Em outras palabras, um for loop é mais "legivel"/"compreensivel" que o reduce(), o mesmo vale para "compreensões de lista".
Você jovem dev, não vá no hype desses papinho de "eu não uso isso, eu não uso aquilo", lembre-se código bom é código simples. A "beleza" de um código é inversamente proporcional a sua complexidade.
Opa, o Java desde a versão 8 está mais para o meio desse quadro aí...
Excelente vídeo.
beeeeeem mais ou menos.
o hype do paradigma funcional, pra mim parece, a mesma coisa que aconteceu com o paradigma orientado a objetos mas so o tempo pode responder
@@user-db2uj9vc7s eu suspeito que não. o hype do OO aconteceu porque as pessoas tavam cansadas de se bater com C, Pascal e Fortran. com o tempo se percebeu que OO não é tão bom assim e que gera inúmeros problemas de manutenção, escalabilidade, performance, representação de dados e organização de código. o paradigma funcional (de verdade, não o que o JS faz) é perfeitamente reutilizável porque as funções são todas puras. não existem bugs tipo null reference ou bobagem desse tipo. é uma pureza matemática que OO nunca teve, OO foi baseado em achismos
Que descoberta esse canal
conteúdo true
Que program é esse que tu usa pra desenhar e escrever?
Excalidraw
Dev senior de verdade NÃO fala "não pode usar else, não pode usar for, tem que usar xpto...". Tudo tem sua utilidade e momentos, igual design patterns. Um laço for por exemplo, será mais performático que um .sum ou .reduce dado o custo da chamada de função, é o mesmo caso da recursividade, código interativo é mais rápido. Agora tem que ponderar com relação a legibilidade, eu uso muito .map e .find e . filter do js, mas não uso .reduce ou .foreach. O pessoal do anti "else" sempre puxa pros casos mais absurdos onde o código tem um zilhão de if aninhado e já teria que ser reescrito igual (se possível, pois existem situações raras que não vale a pena ou dá).
eu uso else quando estou sem paciencia kkkkk
O for loop sendo implementado implicitamente dentro da função nativa
Isso é verdade para algumas linguagens, apenas. Elixir provavelmente faz como Ocaml e F#, utilizando recursão/TCO
Depende, se vc estiver usando js, os array methods, como o map, ele funciona de forma concorrente, é mais rápido, mas pode ter problema de concorrência, por exemplo em um banco de dados, retornando erro de relacionamento errado
Faz um While então
slk depois de tanto programar em JS a syntax do python me parece muito feia
SUM e REDUCE fazem a mesma coisa?
dá pra usar reduce pra soma dos elementos do array, mas o reduce é de uso super geral, você pode usar sempre quando precisar passar por todos os elementos do array e, com base neles, reduzir o array a algum outro valor
tem que entender qual o papel do "acumulador" e do "valor inicial" pra tentar entender melhor os casos de uso
Acho for mais rápido, menos memória, menos variáveis, menos trabalho para o gc.
Iteração é muito mais performática do que invocação de função
@@GutoGalego Você sabe que o artigo que você mandou está justamente indo de encontro o que o Heraldo falou ali em cima né?
"Both for and for..of are 3.5 times faster than reduce. However, the loops are much more verbose"
fale por sua linguagem :) em rust, o uso dessas funções compila pra exatamente o mesmo assembly que se você escrevesse a iteração na mão.
Quando eu vejo o pessoal falando "estou aprendendo demais com os seus videos" acho que evidencia o quão baixo é o nivel de um programador médio, mostrando que esse papo de que o mercado está impossivel é só um monte de iniciante ou pessoa que não sabe programar de maneira efetiva tacando a culpa em qualquer coisa que não seja a si própria.
O jeito que ele traz os videos são muito bons, mesmo eu discordando de muita coisa, tomara que ele traga conceitos ou ideias de niveis minimamente dificeis. Eu ainda prefiro muito mais esse cara do que um youtuber de fofoca.
Veja, o problema da produção de conteúdo é que quanto mais "difícil" e complexo é o teu conteúdo menos gente vai ter pra consumir ele. Acho q o papel dele tá sendo bem maneiro, apresentando soluções de senior pra qm é mais newbie
Ou seja ..... você "terceirizou"a criação do FOR .... trocou um FOR feito por você, pelo FOR feito por um programador MAIS EXPERIENTE .... perfeito ....
E se eu wuiser fazer uma coisa pra cada jtem do array
Se eu entendi bem tua pergunta, aí você pode usar combinações de map, filter e reduce no mesmo comando! Mesmo porque essas três formas aceitam funções como parâmetro inicial, e a função que você vai passar pode influenciar nos itens da array!
@@supermalavoxNão entendi. Pode mandar um código exemplo do que você quer expressar?
@@Zeuszsz, acho que o que ele quer é uma espécie de combinação de map e filter, como por exemplo só fazer algo no array se esse array (ou list no caso do Python) tiver a característica x.
Por exemplo, só multiplicar por dois os itens da lista que forem ímpares.
@@supermalavox array.map( value => {
if (value === "alguma condição") {
"faz alguma coisa"
}
})
Resumindo, pra deixar de usar o for vc coloca ele dentro da function
Não vi C# no conteúdo
o cara parece o cariani kkkkkk
que exemplos são esses cara? meu deus... falo nada
FP >
Nao muda nada, visualmente um loop é muito mais fácil de entender, não muda nada na velocidade de percepção do usuário final. Esses vídeos de faca isso e não aquilo é só baboseira
Grande porcaria. Quando for compilado vai virar exatamente a mesma coisa. É basicamente uma função que faz o loop pra você.
somente pessoas com altos niveis de psicopatia usando .reduce
eu fazendo filter com reduce kkkkkkkkk