Gracias, JavaScript. ¿La habéis entendido esto o qué? Cadenas de texto, 1, 5, 1, .map, parseInt, y sale aquí un none. Está muy chulo porque esto es un error bastante más típico de lo que parece.
Hay gente que se cree que es culpa de JavaScript, de hecho hay gente que me lo ha dicho, menuda mierda de JavaScript. Y me hace gracia porque realmente no es un problema de JavaScript y puede ser, yo creo, fácilmente replicable, creo que en Python, porque Python creo que también se pueden pasar funciones como parámetros, si no me equivoco, no me acuerdo.
Creo que sí, o sea, es que es algo muy típico las funciones de primera clase. Vamos a ver esto, que está interesante. Es por el parseInt. Bueno, es por el parseInt, obviamente, ¿no?
Pero mucha gente cuando ha visto esto ha dicho, pero ¿por qué? Y le ha volado a la cabeza. Porque si hacemos esto mismo así y le pasamos el número, le pasamos al parseInt, vamos a ver que entonces sí que funciona correctamente.
¿Ves? Cuando lo hacemos así sí que funciona correctamente, que es como esperaría todo el mundo que funcionase, ¿ok? Vale, aquí tiene sentido.
Pero ¿por qué la primera línea no funciona igual? Y funciona así. Esto suele ocurrir muchas veces cuando utilizamos como argumento una función, que no vemos visualmente qué parámetros se le está pasando.
Y esto también pasa en un montón de sitios, ¿eh? No tiene nada que ver con JavaScript en realidad. Esto lo que tiene que ver es más bien de la programación funcional.
No es una cosa de JavaScript como he visto por aquí. Había uno que decía, ¡menuda mierda de JavaScript! Es porque el creador de JavaScript, no sé qué.
A ver qué dice por aquí. Es más divertido... No me acuerdo... Creo que por aquí alguien lo ha puesto.
Lo siento, Midu. Tiene sentido para el creador de JavaScript que no sé qué se fumó ese día que lo creó.
Es totalmente contraintitutivo, por lo tanto JavaScript será un lenguaje muy utilizado, pero mal diseñado.
En realidad tengo que decir una cosa. Que sé que no le va a gustar a Oscar, que al final lo digo con todo mi cariño.
¿Ves? Y encima... Claro, he dicho. Yo lo que siento es que creas que es un problema de JavaScript cuando en realidad estás apuntando a que no sabes cómo funciona algo típico en el mundo del software y la programación funcional.
Que no es que no tiene nada que ver.
Y dice, ¡ay, Midu! Tengo 32 años programando. Empecé con Basic y C y voy por Rust.
Sigue siendo contraintitutivo. Por favor, Pershing debería fallar de entrada, ya que se espera dos argumentos.
Y si toma uno, pues falle. Si pasa tres a la vez, pues que falle. Conclusión, mal diseño.
La verdad es que no tiene sentido. O sea, puedo entender que él crea que JavaScript es contraintuitivo, pero la verdad es que, no sé, en esto que dice no tiene sentido.
No tiene razón, ¿eh? ¿Por qué? Es intuitivo cómo funcionan las funciones de... como funciones de primera clase.
Que se puedan pasar como argumentos y todo esto. Os explico por qué.
Lo que está pasando aquí es que el map aquí está recibiendo tres parámetros.
Uno, el primero sería el número. El segundo sería el índice. Y el tercero es el array original, que serían los numbers, ¿vale?
Aquí, en numbers, tenemos este array. ¿Y qué es lo que pasa aquí? Pues que aquí le estaríamos pasando el número, el index y el numbers.
Esto es lo que estaría pasando. Por eso vemos esto. ¿Y dónde aparece este num? Pues aparece porque el index en la primera iteración es cero,
en la siguiente iteración es uno y la siguiente iteración es dos.
parseInt lo que recibe como segundo parámetro es el radix, que sería como la base a la que quieres transformar el número.
Por ejemplo, el parseInt, si tú el string lo pones sin base, por defecto va a ser la base correcta.
Por ejemplo, 10 en base normal, la base que conocemos del 1 al 10, pues sería 10.
El 12 sería el 12 y así estaríamos todo el día.
Pero el 10, si empezamos a poner otras bases, el 1, por ejemplo, no existe la base 1, porque no puedes poner ningún...
No puedes representar el entero en base 1, pero sí lo puedes hacer en base 2.
Y aquí ahora, pues ya podríamos ir viendo, ¿no? Como van cambiando los números, ¿vale?
Y pues constantemente ya no tenemos aquí muchas bases ni nada, ¿vale?
Aquí podríamos seguir contando y poner diferentes bases y tal.
El tema es que esto ya no se utiliza, porque no suele ser muy buena idea utilizarlo,
y por defecto ya utiliza la base correcta.
Y por eso, ahí tendríamos el problema, que en el parseInt, aunque tú no lo veas,
le estás pasando sin querer el segundo parámetro al método de parsInt.
Esto es curioso, porque muchas veces sin querer, y por hacerlo programación funcional,
hacemos esto y no nos damos cuenta de lo que está pasando realmente.
Que esta función se está utilizando tal cual y le está pasando los mismos argumentos que recibe esta función, ¿vale?
Ahí es donde está un poco el problema.
Pero no es un problema ni de JavaScript, ni de parsInt, ni de nada.
Simplemente es un problema nuestro, porque lo que está pasando aquí es que le está pasando un argumento que no esperamos,
porque esta función no está preparada para ser el callback del map.
Aquí tendríamos que tener un callback que espera una, digamos, como un contrato.
Y el contrato pues tiene que ser que el primero sea el number, el segundo es el index, este sea array.
Este es el callback que esperaría aquí y nosotros le hemos pasado una función que nos ha dado la gana.
Y que aunque esta persona, con todo mi cariño a Oscar, dice que el parsInt debería fallar de entrada,
eso no es una mentalidad correcta de un programador.
Porque pensad que si tú creas un callback tal que así, JavaScript o Rust o quien sea,
no va a ser capaz de determinar que si lo que haces aquí pues tiene sentido con los parámetros de entrada que le estás pasando y ya está.
Tiene que ser una caja negra, no es capaz de saber si realmente, no por el tipo de dato,
sino que esto en lugar de ser un índice es la base a la que quieres transformar el número.
Al final los dos son números, así que es imposible que tenga sentido que sepa si el número que le está pasando tiene sentido dentro de ese método.
No tiene sentido.
Es bastante interesante para que lo tengáis en cuenta.
Si alguna vez os pasa, tened cuidado con la programación funcional muchas veces
porque lo que pasa aquí es que si hacéis esto no funciona
y a veces por escribir un poquito de más pues no hacemos las cosas bien
y así os aseguráis que estáis pasando el parámetro que esperáis
en lugar de pasar más argumentos de lo que esperáis.
Eso ha sido el tema que obviamente si me pasáis el number esto sí que funcionaría correctamente
porque number solo recibe un parámetro y los demás los desecha y ya está.
Pero si utilizáis ParSync, pues ahí vais a tener problema.
Como programadores debemos saber si son compatibles.
Claro, es que es un poco problemático el hecho de pensar que es que es el lenguaje el que te da la responsabilidad.
Entonces sí que nos vamos a necesitar.
No entendí eso de las bases.
A ver, lo de las bases no tiene mucha historia.
La base es el entero que representa la base de la cadena.
O sea, tú lo que vas a querer es convertir la cadena de texto en un número
pero tú le puedes indicar cuál es el entero, la base especificada.
¿Por qué la base?
¿La base en cómo funcionan nosotros los números?
Mira, lo vamos a ver más claro así.
Si nosotros tenemos el ParSync, le decimos que es el 10, ¿vale?
En base 10 va a ser el 10.
Pero si le decimos que es sistema binario, esto es el 2, ¿vale?
Si le decimos que es el 01, esto es el 1.
Si es el 00, es el 0.
Y aquí lo que puedes ponerle es una cadena binaria porque le estamos diciendo que es la base binaria, ¿vale?
Entonces es el 00, 00, 1, esto es el 1.
Esto sería el 2, ¿vale?
Esto sería el 3, ¿vale?
Esto sería el 4 y así constantemente.
Esto sería el 5, ¿no?
Estaríamos pasándole aquí ya en base binaria.
Le estamos indicando que esta cadena de texto en base binaria y no lo transforma al entero.
O sea, es interesante esto para cuando utilizamos una base diferente a la típica.
Claro, si aquí le pongo 10, pues se va a volver un poco loco.
Me dice 101, pero porque se la ha inventado.
Está forzando mucho.
Pero imagínate incluso también la hexadecimal.
Podríamos utilizar la hexadecimal y aquí podríamos decir el 1 sería el 1.
El 9 sería el 9.
El 10 sería el 10.
Ah, no.
Es claro, el 10 ya no sería el 10, obviamente.
Porque la hexadecimal ya pasaríamos a que el a sea el 10.
El b es el 11.
Y, por ejemplo, pues ya podríamos hacer aquí a a a.
Y tendríamos aquí, pues, 2730.
Porque en hexadecimal ya sabéis que va del 0 al f, ¿vale?
Como los, el 0, 9, f, como los colores están hexadecimal, pues va del 1 hacia del 0 al f.
Así que por eso se le puede indicar la base para ver si es binario, si es decimal, si es del 0 al 9 o si es hexadecimal y todo esto.
Ahí lo tendrías.
Esa sería la explicación.