Cuidado con la programación funcional
Vložit
- čas přidán 26. 06. 2024
- En este video, te muestro cómo evitar un error común en JavaScript al usar parseInt dentro de un método map. Exploramos cómo se manejan los parámetros en funciones de primera clase y desmitificamos por qué no es un problema del lenguaje
Artículo analizado: x.com/midudev/status/17936433...
▶ No te pierdas más directos en: / midudev - Věda a technologie
![MEJORES y PEORES Áreas de la PROGRAMACION🤑¡Trabajo & Demanda!📚 [TIERLIST]](http://i.ytimg.com/vi/iX24XCa67V4/mqdefault.jpg)
![MEJORES y PEORES Áreas de la PROGRAMACION🤑¡Trabajo & Demanda!📚 [TIERLIST]](/img/tr.png)
Entiendo por qué el amigo no lo entiende. En Rust, un parámetro, en principio opcional, debe especificarse y validarse en tiempo de compilación. Por eso el comentario de "parseInt debe fallar si no recibe ambos parámetros" es bastante comprensible, porque en lenguajes compilados, todo debe ser explícito.
llegué a la misma idea.
Pero esque si que está recibiendo los parámetros.... Ya fuera compilado, interpretado o edulcarado con mayonesa dulce
@@Awakatoso pues llegaste mal
Es que JS/TS tiene muchas cosas que pasan sin que uno se entere. En principio, nada en la síntaxis indica que el parseInt recibe los tres parámetros implícitos del método map
Sí
Hay que admitirlo, como dicen en redes, es un error de capa 8 😅
Dotnet resolvió esos problemas tipando las expresiones lambadas y funciones (Func, Action, Predicate, etc) o incluso tipando la expresión a ejecutar del código (Expression) por ej el código escrito x => x == "abc" lo puedas analizar y dar como output un texto como $"is xyz equals to abc?"
Venía a decir lo mismo, no es un problema de programación funcional, si no de la implementación de js y su falta de tipado y compilación.
@@SkillisForNoobs eso mismo estaba pensando
@@SkillisForNoobs Entonces el problema es del programador que elije usar un lenguaje no tipado sin saber como funciona.
@@SkillisForNoobs exactamente. No entiende nada el flaco que explica. Problema de la programacion funcional dice, un falopa barbaro.
En lenguajes functionales este tipo de functiones de map, filter, etc suelen tomar sólo 1 parámetro y si se necesita el índice, existen derivados con nombre como "map_indexed" y demás. Además Oscar tiene mucha razón, esta clase de errores tontos se pueden capturar en compilación por un buen sistema de tipado.
También en un lenguaje funcional puedes hacer aplicación parcial, por lo tanto una función como parseInt estaría diseñada de tal forma quepodamos pasarle algo como parseInt(10) que crea otra función que hace parsing en decimal (radix 10). o parseInt(2) para binario,etc etc.
A mí me suena más a un problema del tipado dinámico y débil que de la "programación functional" combinado con un diseño cuestionable de las funciones de orden superior en javascript y un poquito de falta de conocimiento sobre cómo funciona el lenguaje y las funciones de la librería estándar.
Eso de generar funciones lo he visto con d3JS donde se tiene que hacer para las coordenadas
Exactamente esto no es un problema de programación funcional es de tipado dinámico
@@bernardoherrera5217 ahí vamos. Si no sabes lo que necesita el metodo o función, no sabrás que lo estás haciendo mal
@@wil-fri eso es bueno de los lenguajes fuertemente tipados, porque te obligan a seguir las reglas, y errores como esos no pasan, bueno a coste de más verbosidad
Hola midu, cuando explicas la base 10 dices que se lo está inventando. Pero realmente al igual que 101 en base 2 es igual a 2² + 2⁰ = 5 en base 10 sería 10² + 10⁰ = 100 + 1. Muy buen video.
parseInt() retorna solo enteros, esa es la razón. La explicación sencilla es que en base 10 no existen números con entero 0 a su izquierda, por eso 0002 en base 10 es igual 2, mientras que por ejemplo algo como '23abc45' te retorna 23 porque es el primer entero posible en la cadena e ignora todo lo siguiente porque es cortado con los caracteres alfabéticos que no existen en base 10, por lo cual toma todo el segmento posterior al entero en el string como descartado. A veces la gente se confunde y toma parseInt como algo que retorna una conversión numérica de un string, pero en realidad devuelve un parseamiento de un entero a partir de un string según la base especificada, y esa es una diferencia a tener en cuenta.
Eso es un paradigma de programacion llamado "programacion tacita" o "point free", si bien algunos lenguajes funcionales la usan no son todos y no es algo exclusivo de la programación funcional. Ademas no entiendo porque casi siempre terminan reduciendo la prog funcional a un simple map/filter/reduce cuando el paradigma es inmensamente mas grande, estaria bueno que algun dia hablen de los functors, las monadas, los aplicativos, los monoides o algo tan simple como el curry o la aplicacion parcial y no terminen reduciendo un paradigma a 3 funciones...
> no entiendo porque casi siempre terminan reduciendo la prog funcional a un simple map/filter/reduce
En general hay mucha ignorancia cuando se habla de paradigmas de programación. He trabajado con gente que "odiaba OOP" y luego me di cuenta de que nunca lo aplicaron correctamente.
Cuando los temas son tan generales y, a primera vista, bastante simples, mucha gente se siente cualificada como para hablar y opinar al respecto.
Se debe caer siempre en los mismo por que es lo único que se usa. Estaría bueno conocer más a fondo como dice el amigo y no siempre hablar de lo mismo
@@numeritos1799Fuera de la ignorancia y que la gente a veces es perezosa (claro ejemplos es el odio a java, gracioso porque prácticamente todos los lenguajes opp de su época eran igual de verbosos y usaban metodologías bastante abstractas frente a las mas nuevas como python), es que la gente no usa programación funcional, requiere tiempo, mayor uso de abstracción y muchos de los lenguajes ya usan otros paradigmas que usan más y se pueden sentir más cómodos que volver a ser junior para entenderle a los temas avanzados del funcional, me incluyo en eso
Totalmente
En el video te lo explican amigo, no se sabe porque es pecado 🥶
Me encanta cuando la gente empieza a recitar su CV diciendo que lleva programando desde la época de los dinosaurios. Da igual que lleves tanto tiempo, te puedes equivocar igual:/
Tiempo q se pierde publicando en ves de analizarlo... igual aplica para mi comentario jajaj
Es simplemente que en su trayectoria profesional parece haber usado lenguajes con características muy diferentes a JS.
Tiene su razón de igual modo, Olvidate de la experiencia.
7:15 no se lo ha inventado simplemente 000101 = 101.
La verdad no tengo experiencia profesional con JS, pero que este codigo no falle si que me parece contrainuitivo:
function hello(name) {console.log(name)}
hello("google", 2) # "google"
Posiblemente un poco porque en JS puedes declarar una firma en una función, por ejemplo recibe 2 parámetros, y cuando la mandas llamar le puedes pasar los parámetros que sean jaja, si le pasas menos de 2, los restantes quedarán undefined, si le pasas más de 2, solo tomará en cuenta los primeros y los restantes los ignora, por eso parseInt (que recibe 2 parámetros) lo puedes asignar como un callback con 3 parámetros.
Una cosa es contraintuitivo y otra que no conozcas lo que hace el map, si la callback del map recibe esos tres parámetros y el parseInt sus 3 propios pues es lo que hay.
La callback del map no puede ser tan "inteligente" como para saber que argumentos espera recibir según que método le pases.
busca "funciones variadicas"
$ const hello = (a, ...rest) => console.log(a, rest)
$ hello("a", "b", "c") => a [ 'b', 'c' ]
Opino igual. Hasta ahora solo he usado Java profesionalmente y me voló la cabeza la primera vez que vi ese comportamiento en JS. Me parecía muy confuso que la función no reciba exactamente lo que se le declara como parámetros y no falle
@@fready_star Java es un lenguaje compilado a diferencia de JS que es interpretado. Un lenguaje compilado siempre tendrá más chance de ser más estricto en cuanto a tipos y estructuras porque eso se revisa justamente en la compilación.
Como me encanta mirar al Midlu explicando aunque no le entiendo un carajo, debo decir que es por mi porque es excelente explicando. Saludos genio
No sabía eso del. ParseInt. Gracias midu
En teoría, la función map recibe una función, anónima o no, que recibe 3 parámetros, pero puedes pasarle una que reciba 1, 2, 3, 4 o 57 parámetros, rellenando con undefined los parámetros extra. ¿Esta gochada también la permiten otros lenguajes?
Si, JS no está tipado, podes pasarle lo que quieras.
si vas a pasar a un callback que recibe 8 parametros a una funcion que solo le va a pasar 3 entonces que haces que no sabes usar el lenguaje? Es igual que no sepas que no tenes que intentar acceder a una posicion X en un array en C si este esta fuera de sus limites
Tiene sentido por lo que asi funciona parseInt, sin embargo con respecto a otros lenguajes donde solo se pasa 1 solo parametro resulta contra intuitivo el recibir mas de 1 parametro en el map
En este caso en concreto difiero un poco con tu opinion Midu.
En mi opinion SI es un mal diseño en javascript.
Si nos remontamos a los origenes de la programacion funcional, su raiz es el calculo lambda, en el cual las funciones puramente admiten un parametro de entrada (que con conceptos como la currificacion se pueden tomar varios parametros, pero sigue siendo uno solo en forma de tupla).
Asi mismo, muchos otros lenguajes de programacion, en sus caracteristicas funcionales, siguen la regla de "1 parametro". Por ejemplo, en Java, cuando pasas una referencia de una funcion, solo se usa una sola entidad como parametro (o nunguna si la funcion referenciada no toma parametros) pero nunca dos o mas. Para poder usar mas parametros siguiendo este patron, se recurre a tecnicas como usar estructuras u objetos especificos que contienen los parametros necesarios.
ahora que mencionas lo de la tupla, vone yo a comentar que así es en python y que si quieres pasar múltiples parámetros puedes hacerlo empaqutando con la función zip() o pasando una tupla, sí
Al final de cuentas me hace acordar a la sobrecarga de metodos en java, (varios metodos pueden tener el mismo nombre pero no los mismos parametros en un mismo momento) por lo cual no se en javascript con algun ide tipo visual studio si podes acceder al js base del parseInt por ejemplo, pero en java con el manejo de clases basicamente le das ctrl + click a un metodo abris su implementacion y ves tal cual lo que esta recibiendo en el use case que estas utilizando, de igual manera eso en java de poner map(parseInt) no se puede, pero si se podria como pusiste al principio algo como map( n => parseInt(n)) . Respeto a los desarrolladores en JS porque hay mucha magia detras entre las funciones y el front, pero me sigue enamorando mas Java para toda la logica de negocios en las aplicaciones.
Atte: Un Java Senior Developer con 10 años de experiencia ♥
Que le paso al titulo jajaja
Qué decía ?
@@zaitsev5990 Decia "Menuda 💩 de JavaScript" osea literalmente decia eso, con el emoji incluido xd
@@zaitsev5990 menuda m* de JS creo
@@rip.vanwinkle si si, yo recién veo que le cambiaron el título
Jajajajajajaha
Creo que lo que quiere decir Oscar no es que javascript deba ser inteligente y entienda para que usas los parámetros. Yo lo que he entendido es que, según él, javascript debería fallar cuando a una función que espera como parámetro otra función tal que `(param1, param2, param3) => ...` recibe una función tal que `(param1, param2) => ...`. Creo que su queja va por el camino de que a javascript le da igual que a una función le pases un argumento, dos o cero, independientemente de que la firma de la función especifique que debe recibir n parámetros.
Midu, eres un ejemplo de cómo ayudar y comunicar. Mañana me llega tu libro de git por cierto. Espero mucho de él... Gracias por todo lo que regalas...
en elixir podemos hacer algo asi, supongo que es la solucion con programacion funcional:
parse_int/1
parse_int/2
por como es javascript, si, que no "falle" tiene sentido, pero en otros lenguajes, si fallaría debido a que no tiene sentido en el callback y sería bueno que lo revise. En definitiva, ese es el problema con javascript, ser muy permisivo lleva a bugs muchas veces.
En efecto, en JS puede no coincidir los parámetros que declaras contra los parámetros que le pasas al mandarla llamar, pero qué se le puede pedir a un lenguaje interpretado y cero tipado jaja.
Por eso tira de typescript siempre que puedas.
Creo que el del mensaje de twitter se refiere mas a la sintaxis, esa sintaxis lleva a equivocos de este tipo donde no sabes que pasas a la funcion.
Muy interesante, como nunca entendía como eran las funciones como parámetros casi no las usaba
La explicación es buena y me hace sentido, pero estas son cosas que me molestan que al final es poco intuitivo en varios aspectos
umm... vale si es mas un desconocimiento de lo que le esta pasando map, uno podría pensar que se le pasan los mismos valores que en otros lenguajes por lo parecido pero en el fondo realmente es diferente. Creo que es un poco culpa de ambas partes del programador por desconocer eso y de la persona que enseña a usar ese método ya que por lo general enseña esos otros parámetros pasados por defecto desde un principio
Javascript es como si en un concierto de Taylor Swift no cobraran por los tickets de entrada. Imaginen todo lo que va a pasar por esa puerta...
Como hater de JS he de asumir que esto es falta de leer la documentación, aunque sea contraintuitivo no está mal
Este tipo de errores tan poco perceptibles fuera de debug lo único que van a ocasionar es que si acabas cometiendo uno, acabes gastando más tiempo y por ende amplíes los costes del proyecto.
Tampoco hay que olvidar que no siempre estamos en nuestro mejor día de programadores, puede que aún conociendo el funcionamiento se te escape el error y luego tengas que buscarlo.
@@alexps6522 no sé si es tan poco perceptible, llegar y usar una función sin leer cuáles o cuántos son sus argumentos me parece un error del programador, no del lenguaje. Y no lo digo con superioridad moral, tb me pasa, pero no por eso culpo al lenguaje.
@@alexps6522 si sabes usar map,. sabes que debe recibir una callback y cada iteración puedes hacer lo que quieras con el elemento en cuestión.
Si no usas así el map es que no ssabes usarlo.
(No te lo digo a ti personalmente eh)
Ha sio brutal! Gracias MiduGod
mh... en python usas map pasandole una función e iterables, si lo que quieres es pasar n parámetros, lo suyo es empaquetar con zip() y te puedes hacer por ejemplo una lista con m paquetes que cada uno contiene n parámetros. Estoy también con que no es un problema de javascript, sino de entender como funciona (en este caso) el método. Para la gente que usa lenguajes fuertemente tipados es contraintuitivo, pero no se le puede echar la culpa a un lenguaje de como funciona map en ese caso particular.
Llevo años programando en java, python y TS, y puedo decir que es mucho mas intititivo y comprnsible que "falle", pero no es la culpa de javascript, haces un lamda en python y tambien pasa
Un ejemplo más puede ser cuando tratas de elevar 0 a 0, que muchos lenguajes lo toman como 1, cuando es indeterminado matematicamente
Qué intuición tienen o con qué "intuición" vienen. No parece muy elemental que les ocurra que funcione de esa manera como quieren, pero sí que como un extra aplicable sería.
Quizás algo como [1,"2",3].map(*parseInt) para corresponder solo un parámetro, [1,"2",3].map(**parseInt), para corresponder dos...
Para esta sintaxis solo igualarían numeroDeAsteriscos+nameFunction = (...n)=>nameFunction(n.slice(0,numeroDeAsteriscos))
Tampoco que una urgencia.
Función de parámetro, primero se resuelve la función, y el valor del resultado queda como valor, aunque sea NaN o Null, o null, dependiendo del lenguaje.
jamás habría pensado de usarlo así ['1', '5', '1'].map(parseInt);, siempre lo uso con los parametros que requiero ['1', '5', '1'].map(n => parseInt(n))
Creo que en realidad es problema de tipado, en la compilación js no marca errores de compilacion al usar tipos que no tienen la misma declaracion de en este caso parámetros, en lenguajes con kotlin que tambien es funcional marcaria error de compilación al no tener los mismos tipos.
uff, imaginense entonces cuando entren a la discusion de recursividad vs iteracion en la programacion funcional. Las respuestas que hay ahi para justificar por que elegir iteracion vs recursividad son increibles. Como dato, Structure and Interpretation of Computer Programs explica bien esto desde el capitulo 1
Gracias midu, como lo explicas tiene mucho sentido. Por cierto: qué herramienta usas para que te arroje el resultado mientras realizas el ejemplo:
Eso que dice Midu se visualiza con: ['1', '5', '1'].map( console.log )
hay que saber como funciona map y parseInt, se puede solucionar haciendo un 'partial' para definir dos de los parámetros de parseInt
te quiero mucho Midu ❤
¡Gracias! Esto no es un problema de programación funcional es más bien del tipado dinámico, yo he programado en Scala por mas de 3 años en programación funcional y ese tipo de problemas no pasan, ni siquiera compilaría, eso se debe al tipado dinámico, y va a pasar en Python por exactamente lo mismo, no por la programación funcional
Es que el método map (en cualquier lenguaje funcional) acepta un callback con solo un parámetro. Es problema de que si js quiere hacer cosas en funcional, debería hacerlas como lo hacen los lenguajes funcionales
¿Por qué?
@@itzmegaskz Si uno quiere incluir características de lenguajes funcionales, debería hacerlos tal y como lo hacen los lenguajes funcionales (que es donde se ha investigado el tema y se han alcanzado soluciones). En los lenguajes funcionales (hasta donde sé, en todos), map siempre recibe un callback con un sólo parámetro. Si quieres pasar más de uno, pasa una tupla o utiliza currificacion o algo por el estilo, pero esta implementación es una chapuza
Gracias dios midu, nunca me había quedado tan claro que los errores no son del lenguaje sino del programador
Es evidente que el programador es el que se equivoca
La cuestión es...
¿Algunos lenguajes ayudan más a que cometas menos errores?
Somos humanos y "errare humanem est"
si es más fácil hacerlo mal que bien... terminarás haciéndolo mal
Hay lenguajes que siguen sorprendiendo a programadores con años de experiencia
Hay lenguajes aburridos, que no sorprenden a programadores con poca experiencia (suelen ser funcionales)
Y sí hay errores en los lenguajes de programación, que muchas veces se intentan corregir
El experto sin ego: llevo 32 años programando, JS está mal.
Midu: esa no es mentalidad de programador.
No pude no reír jaja. Qué gran lección de humildad. A veces cuando alguien cree saber mucho se le olvida algo tan básico como pensar dos veces antes de opinar. El ego...
Creo que lo que oscar quiso decir es que si parseInt espera 2 parametros, si le pasas 3 deberia fallar
Sí, es una cosa de javascript.
Ahh claro, no lo había pensado.
Que gracia
Es solo desconocimiento de cómo funcionan las cosas. Con los años vamos perdiendo flexibilidad en el aprendizaje en general. Ya me está pasando. Pero lo que no hay que olvidar, es admitir que no podemos ni debemos saber todo y también que siempre puede haber alguien más que si sepa y ser humildes en aceptar lo que sabe. Saludos
Cual es ese intérprete a tiempo real de js que usa?
Para salir de dudas, se puede rutear la misma función parseInt, y codificar en consecuencia.
hay gente toxica, midu solo explica que hay que asegurarse que parseInt reciba el valor actual de cada iteración y no el índice
Hermoso video
Esto no pasa en ningún otro lenguaje que conozca (Ruby, Python, etc). Si está haciendo un map de un array, no es del todo intuitivo que se pasen los otros argumentos a la función.
Ambas array.map(parseInt) o array.map(n => parseInt(n)) son "programación funcional". En ambas se está pasando una función como argumento.
Decir que esto error se da por "programación funcional" y no por la implementación específica de Javascript me parece bastante forzado.
Disclaimer: la razón por las que pongo las comillas sobre "programación funcional" es porque functions as values != programación funcional. Son conceptos relacionados, sí, pero no son lo mismo.
Más contraintuitivo es que en JS un Array vacío no equivale a false
Si existe la base unaria, que quizás no sea útil o que no lo hayan implementado es otra cosa.
No tiene por qué fallar una función que recibe 2 argumentos al recibir 3. Podría fallar al revés, que solo reciba 1 argumento, pero ambos casos depende de cada lenguaje de programación y como esté hecha la función, los lenguajes de tipado dinámicos e interpretados suelen ser bastante permisibles.
Es mejor usar `Number`.
Cómo que no es un problema de JS xD, si parseInt recibe 2 argumentos como máximo, y si se pasa esta función como callback al map, va invocarla con 3 parámetros, en ese sentido debería lanzar excepción por la cantidad dispareja, porque se reciben 3 y se esperan 2, así funciona JS, a una función se le puede pasar 1 millón de parámetros aunque se declare la función con 1 solo, lo que va a hacer JS es tomar el primero e ignorar todos los demás. Si map enviara 2 parámetros, si estaría contigo Midu, ya que se esperan 2 y se reciben 2
sabias que si cambias el nombre al video, la notificación queda con el nombre original del video? pues ahora lo se 🥶
Como se llamaba antes el vídeo por curiosidad
No me explico porque el primer resultado da 1, es decir como es posible que parseInt('1',0) en este caso, 1 no es un numero valido de base 0 por lo que tambien seria NaN
El radix (el segundo argumento) acepta los valores 0,2,3,4....36 (en palabras: el cero y luego del 2 al 36).Cuando es cero la función se comporta igual que cuando no se ingresa un argumento
@@Turko77777 y cuando es 10 también?
@@mikelucii6030 cuando es 10 toma la base 10, que es la que usamos los humanos. Si lo preguntas por lo que aparece en el final del video, el número que muestra es correcto "000101" en base 10 es "101", es decir es exactamente el mismo número, pero sin mostrar los ceros a la izquierda
@@Turko77777 gracias por explicar, bueno, y que pasa cuando uso 36 como base ? que simbolos usa para representar los numeros en base 36?
@@josephmenasandoval3419 Es como el hexadecimal, que tienes los símbolos 0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f. Pero en este caso llegas hasta la "z", ya que de la "a" a la "z" hay 26 letras (sin la ñ) más los 10 números del "0" al "9", tienes los 36.
Yo lo he usado para ordenar cadenas que incluyen números -> ["11b","10b","9a"].toSorted( (a,b)=> parseInt(a,36) -parseInt(b,36))
Midu si hay un problema del lenguaje con el paradigma, tu debes saber como Javascript va a usar los parametros eso esta en el lenguaje
Nada como un buen lenguaje fuertemente tipado y compilado
no me he encontrado con ese error pero porque me gusta ver los parametros que le paso jaja entonces nunca las escribo de esa manera mas corta.
Llevo mucho tiempo programando con lenguajes funcionales y el currying que es lo que asumo que hace JS NO debería funcionar así. En "map" en todos los lenguajes pasa los parámetros uno a uno, si el "arity" de la función es mayor DEBE fallar. El hecho de que se pasen los parámetros según los parámetros que acepte la función es una cagada en el diseño del lenguaje.
en conclusión: joven especifique
En resumen, confían demasiado en el syntactic sugar
No debería tener más bien un comportamiento foreach?
en lugar de pasar todos los elementos del array como parametros ?
Es Javascript, la regla es que no se comporta como otros lenguajes, esto para casi todo
Al menos los tres parámetros de la callback están en el mismo orden, no como en php con sus homónimos array_map, array_reduce, array_walk...😅
interesante, que bueno que nunca hago algo así cuando estoy trabajando con javascript. Eso de las bases me entra por un oido y me sale por el otro, nunca se me queda... creo que es mi problema con las mates.
El cambio de título jajajaja
Menuda mierd de Javascript XDD
El problema es por ser lenguaje dinamico, no te das cuenta de los argumentos, tipos o cantidad , en un lenguaje compilado es lo primero que saltaria o te fijarias, en dinamico infiere todo, y ese es el problema, lo que normalmente hace el compilador y el IDE, en uno dinamico tu cerebro tiene que hacerlo.
Sí es un problema de javascript y no de la programacion funcional.
En la programacion funcional en un map la funcion que usa de parametro solo tiene un parametro (el elemento de la lista), y con ese opera. Es cosa de javascript que te meta otros dos parametros, no es nada intuitivo sobre como debe ser una funcion de orden superior.
En haskell que es puramente funcional solo usa el elemento como parametro de la funcion.
en js no falla pero en otros si....
punto para los otros lenguajes y sí, es un fallo de js (ya sea por diseño o falta de tipado o por flojera 😆😅 etc)
Mejor crear un proceso para traer datos numericos desde el input del programa sin necesidad de añadir el parseInt. Tratar inteligentemente la base de datos.
Hay que entender bien qué argumentos reciben las funciones, como el map. En Haskell es mucho más robusto. La idea original funcionaría porque solo recibe la función y la lista.
CUIDADO!!! No es la programación funcional
es una combinación de factores, en el que la integración de programación funcional colabora en este problema
trabajo con varios lenguajes funcionales, y "no es normal" que ocurran cosas como estas
Acepto que s la integración de programación funcional en js o la programación funcional de js
Pero no generalicemos, en lenguajes funcionales, comportamientos de este tipo es muy difícil encontrarlos
Y se ha mencionado Rust. En Rust, que no es funcional, esto tampoco puede pasar "fácilmente"
Óscar quedó retratado
Que auriculares usas midu? alguien sabe?
@@Martin97perussini En su página de Twitch viene su setup, ahí dice todo lo que usa y si no mal recuerdo también hay un enlace para que lo compres.
@@jorgemacias915 buenísimo, me paso por ahí cuando prenda entonces
La gente quejandose por un lenguaje que se diseño para no romper el navegador se comporta exactamente como se diseñó 😂. Les dejo una pista, el parseFloat cumple correctamente la tarea al usarlo con map
justo termine la clase sobre funciones veamos de que trata el video jaja
Para mi js si esta "mal hecho", ya que si fuese " tipado " no existirian este tipo de problemas.
Midu logré hacer mi chat en linea
Link
mi cerebro no procesa esto
difiero, sigue siendo contraintuitivo y poco tiene que ver con saber o no programacion funcional
es totalmente intuitivo de que si tenes una funcion que le pasa 3 parametros a un callback esta le va a pasar 3 parametros al callback
thanx for explication😅
Yo trabajo con elixir, vengo de php y python. SI, debe reventar con un error, no entiendo como se puede justificar algo así. Hay que asumirlo y punto, si es una mierda! y ya!.
En python no pasa eso
Re interesante :) y a los presumidos, tocar pasto :3
Cuando una venta no cuadraba porque de pasar decimal a valor en centavos hacíamos 9.95 * 100 y daba 994 💀💀💀
pero so boludo, no es culpa de js que no sepas que ecuación tenes que hacer xd
Pero... ¿hay midu?
midu era callarlo no humillarlo
Conclusión, hay que leer las especificaciones del lenguaje y no hablar sin saber
Primera vez que escucho lo de la programacion funcional o puede ser que ya la haya escuchado y no le haya prestado tanta atencion.
Este me lo he comido varias veces 😂
JS debería dar error al tratar de pasar un tercer argumento a una función que no lo espera. Esto es el problema, en mi opinión.
... buuuuuuuuuuuuenazo!!!
1:15 Usando Typescript ya te das cuenta. Jaja
Prueba el new Date("") -> batman
Ok, ok esta vez y en este caso particular no es culpa de javascript, ahora falta por desmentir los otros 1000 casos donde falla.
La coerción de tipos es más mala que escupir a tu madre en su cumpleaños. Es tan mala que se inventaron otro lenguaje (typescript) que opera sobre este lenguaje.
Es un lenguaje pequeño, con pocas funcionalidades. Pero su documentación es extensa, porque está llena de explicaciones de casos excepcionales que hay que considerar. Es tan complejo, que nadie se atreve a hacer un motor de javascript desde cero y llevamos casi 2 décadas con el monopolio de google.
Hace 15 años que se debió haber descontinuado este lenguaje, pero en lugar de eso se lo llevaron al servidor. Una fatalidad
Todo bien con lo que dices, Midu, concuerdo. Pero ahora explicame este parseInt(0.000000005) output: 5 hahaha
parseInt lo que hace es transformar un string en un numero (asi que para q le pasas un numero), cuando le pasas el numero lo que hace es transformarlo en string y posteriormente agarra y lo transforma. 0.000000005 es "5e-9", la funcion comienza a transformar en numero desde inicio hasta encontrar un caracter que no sea un numero, asi que la cadena "5e-9" comienza 5 y despues encuentra "e" asi que deja y devuelve 5
@@gonzaloerceg6816 o sea le pase un flotante precisamente para eso, a ver si lo parseaba a un entero. La explicacion esta tremenda, sigo pensando que es contra-intuitivo (al menos para como yo aprendi numeros enteros y numeros de coma flotante) tener una funcion que te parsea a un entero, pero al pasarle un flotante te devuelva literalmente el valor de la mantissa xD pero weno cada lenguaje es un mundo, no esta ni mal, ni bieen. Gracias por la explicacion igual gonza!
En otras palabras a leer la documentación jajaja
Que si hombre, que sí es culpa del diseño de JS que no ha creado una API para map/reduce/filter que sea consistente para pasar funciones como argumento y le ha enchufado todos los parámetros a la función. Python no habría fallado porque para pasar el contenido de un array a una función hay que usar explícitamente el argument destructuring, en lugar de hacerlo como en JS donde las cosas ocurren mágicamente, te puedes parámetros obligatorios y todo se vale con esa gramática tan de M que tiene.
En lugar de decir que es culpa de la programación funcional (como si algo tuviera que ver), dile a tus alumnos que hasta que aprendan a programar, primero usen un type checker y un debugger, o van a saber lo que es pasar horas con cara de gilipollas frente a la pantalla.
map le pasa 3 parametros al callback y te sorprende que le pase 3 parametros? es culpa de no saber como funciona map, no es tan dificil, hay una documentación muy bonita que te dice explicitamente que map pasa 3 parametros al callback. El hecho de que pienses que las cosas funcionan magicamente es simplemente porque no sabes del lenguaje
Ojo cuidado que tiene 32 AÑOS en la programación no se atrevan a corregirlo :o