2019-10-18 18:00
Episodio 13: Python 3.8
¿Qué trae de nuevo Python 3.8? Un montón de cosas, pero hay 2 en particular que afectan / mejoran / resuelven temas que me molestan desde hace ¡Más de 10 años!
¿Qué trae de nuevo Python 3.8? Un montón de cosas, pero hay 2 en particular que afectan / mejoran / resuelven temas que me molestan desde hace ¡Más de 10 años!
Enfrentado a un problema, uno de los criterios para buscar la solución es el misterioso "que sea pitónico". ¿Qué es eso? ¿Vale la pena usar algo más lindo pero 12 veces más lento? ¿Y cómo sé eso? ¿Puedo mejorarlo? ¿Y si es 2 veces más lento nomás?
¿Qué son los Type Hints en Python? ¿Para qué sirven? ¿Cómo se usan?
Una línea. Estás viendo código y te cruzás con una línea que ... ¿que miércoles es esa línea? ¿Con qué se come? ¿Qué se hace?
Expresiones regulares, intentos de explicaciones poco convincentes y más!
Generadores en Python ... ¿qué son? ¿Con qué se comen?
Un intento (probablemente fallido) de explicar complejidad algorítmica, o por lo menos lo más básico del tema sin complicarla demasiado.
¿Es posible agarrar código al azar y hacer que funcione 1000 veces más rápido?
La verdad es que casi nunca. Pero a veces sí.
Una pseudo secuela de "Puede Fallar" mostrando varias cosas:
Y mucho más!
La aplicación que muestro en el video: En Anvil
El código: lo podés clonar
Detalle: "lo de twitter" quedó reducido a un botón adentro de la aplicación, pero sirvió como disparador :-)
Episodio 3!
Igual que casi nadie publica los estudios con resultados negativos, nadie hace videos en Youtube acerca de como no le sale hacer algo. Bueno, yo sí.
Este episodio es sobre una de las cosas que más me interesan en el desarrollo de software, especialmente para alguien que está aprendiendo (o sea todo el mundo) y más aún para un principiante: el fracaso.
Véanme fracasar durante unos 20 minutos, mientras trato infructuosamente de hacer una cosa que tenía ganas de hacer!
¡Y no pasa nada! Es imposible tener sindrome de impostor si uno no hace como que sabe.
Mucha gente, cuando no sabe programar, tiene prejuicios. Algunos de los más comunes son:
Ambos prejuicios son perjudiciales para ese posible futuro programador por varios motivos. El primero y más obvio es que no son ciertos. Pero no es que no son ciertos en la manera en que "el tomate es una verdura" no es cierto, son falsos de la misma manera que "el tomate es venenoso" es falso.
Eso es lo que lo hace complicado. Porque el tomate ... el tomate es venenoso.
En el siglo 18, uno de los sobrenombres del tomate era "manzana venenosa"1 porque la gente rica solía comer tomates y morir envenenada. Porque comía en platos de peltre, que contiene plomo y el jugo del tomate disolvía el plomo, y comer plomo es malo, gente.
Por otro lado el tomate es venenoso en sí mismo. Es una solanácea, un género de plantas que producen alcaloides. La tomatera produce solanina, un tóxico que provoca diarrea, vómito y dolor abdominal.
O sea, decir "el tomate es venenoso" es técnicamente cierto que es la peor manera de estar equivocado. Lo mismo pasa con decir "para programar hay que saber matemática".
Es técnicamente cierto. Pero no es importante. Igual que es técnicamente cierto que el tomate es venenoso, pero no es importante, y por eso comemos tomate igual.
Me voy a concentrar en el segundo prejuicio, acerca de programar y matemáticas, porque el primero no resiste el mas mínimo contacto con programadores (yo incluído).
¿Por qué es técnicamente cierto?
Por ejemplo, te van a hablar de cosas como números binarios, hexadecimales y hasta octales. Y sí, eso es "matemática" y es necesario para ... ¿para qué, exactamente?
Para casi nada. Estas son las cosas que más frecuentemente encuentres programando para las cuales eso es útil:
Mentira. El uso más frecuente del hexadecimal es buscar palabras que se pueden escribir como números hexa. Aguante DEADBEEF!
Si este año tengo que usar números binarios más allá de saber "un byte cuenta hasta 255" va a ser la segunda vez en la década.
Realmente es una de esas cosas que uno aprende, las guarda en un rincón de la cabeza y después las saca a pasear una vez cada tanto cuando se encuentra con un problema específico, igual que la explicación de la regla del offside o como se organiza un torneo por sistema suizo.
Si querés hacer machine learning tenés que saber hacer regresión lineal. tenés que tener idea de cálculo. Te va a venir bien saber montones de cosas más.
De la misma manera si vas a hacer un sistema de liquidación de sueldos te va a ser útil saber sobre legislación laboral.
Si sos un médico y querés saber si la aspirina hace bien vas a tener que saber diseño experimental y estadística.
Si sos un manager de baseball y querés saber si te conviene comprar un bateador con un OPS de .575 pagándole 23 millones de dólares vas a necesitar probabilidad y estadística y contabilidad.
Si querés programar un algoritmo de crypto tenés que parar y no programarlo porque no es buena idea.
Que para una tarea en particular necesites saber algo no hace que sea un prerequisito para el área en general. Nadie sabe hacer todo. Nadie sabe programar todos los tipos de cosas. Eso es simplemente la condición humana.
Yo no sé hacer todo. Y no, no sé hacer machine learning. Y tampoco te puedo hacer un programa de trading. Y si vamos al caso tampoco puedo hacer una simple media tejida porque no sé tejer.
Para saber hacer cosas hay que estudiar, no hay mucho secreto. Entonces, para programar hay que estudiar como se programa, y para programar algunas cosas en particular hay que estudiar otras cosas también.
Este motivo es más esotérico, pero si, es cierto. La matemática y los matemáticos te van a decir alegremente que el concepto mismo de algoritmo es matemática.
En cuyo caso, obviamente, apenas aprendés a hacer un if ya aprendiste matemática y es imposible expresar un programa sin matemática y pasamos de "técnicamente cierto" a "obvio e inútil". Si todo es matemática entonces el "hay que saber matemática" es una trivialidad. Será que sí, pero ¿cuánta? y ¿cuál?
Si aprendés complejidad algorítmica programás mejor.
Si aprendés suficiente "number sense" para saber cuando vale la pena hacer algo programás mejor.
Si aprendés suficiente probabilidad como para saber si algo es un riesgo que vale la pena atacar programás mejor.
Y varias cosas similares.
Éste es tal vez el sentido en el que estoy más dispuesto a decir que "para programar hay que saber matemática" pero tiene el problema de que no es lo que el receptor entiende cuando se lo decís.
Si el objetivo de comunicarse es que se transmita un mensaje (hey, teoría de la información! Más matemática!) es importante no sólo ser correcto en lo que se dice, es importante que lo que uno dice sea entendido de manera correcta por el receptor.
Así que ...
La matemática es una cosa super amplia, y en la vida nos cruzamos todo el tiempo con ella.
El saber la trayectoria que va a hacer la pelota cuando pateás con comba es matemática. Pero cuando pateás lo hacés sin calcularla porque sabés esa parte de la matemática. No hace falta que la expreses "matemáticamente". no te ponés a calcular el efecto Magnus de acuerdo a la velocidad de rotación de la número cinco y la influencia de los gajos en la aerodinamia.
Programar, en la súper gran mayoría de los casos, se parece mucho más a eso que a lo que te viene a la cabeza cuando te dicen matemática.
Vas a tener que aprender algunas herramientas. Y te las vas a olvidar. ¿Y sabés qué? No hay problema. Las aprendés de vuelta.
Y vas a hacer cosas como mirar un cacho de código y decir ... "ajá, complejidad logarítmica". Y mientras te acuerdes que forma tiene el dibujo comparado con una parábola, hasta ahí llegó lo que te importa en ese momento.
Y a veces vas a tener que meterte hasta las cachas en matemática, y vas a tener que ver como hacer una transformada afín, o como hacer un curve fitting, o un montón de otras cosas. ¡Yo una vez tuve que hacer análisis de regresión para ver como organizar una tabla HTML! ¿Y?
La matemática está por todos lados. Para programar vas a usar matemática. También podés usar matemática para vender chancletas.
No es que sea falso que "para programar hay que saber matemática" es que no es interesante.
De ahora en más se van a imaginar a Blancanieves morfándose un tomate. Sorry. ↩