Sobre el Copilot y lo de repetir código

Minientrada

No estoy siguiendo mucho el tema de GitHub Copilot más allá sobre los memes que ya se han hecho, así que tampoco puedo contar nada innovador.

A los programadores nos encanta soltar siglas para todo. Una de ellas es DRY: do not repeat yourself. Resolver continuamente los mismos problemas y reescribir el mismo código es absurdo porque provoca código complicado de mantener. El código debería ser reusable.

Excepto que no todo el código acaba siendo fácil de reutilizar. O, al menos, puede ser bastante excéntrico tratar de reutilizar cierto código. Crear librerías de funciones útiles que hagan las cosas sencillas pero que la librería estandar de nuestro lenguaje de programación no nos proporcione, o marcarse un Node.js y tener un ecosistema lleno de paquetes monofuncionales (en el sentido más literal de la palabra) para hacer cosas como comprobar si un array está vacío, si un número es par, o para introducir espacios en una palabra.

«¿Un paquete para crear un array de N posiciones en JavaScript? Eso es absurdo». Posiblemente. El zero-dependency es un estilo de vida, y en el caso de lenguajes como JavaScript, reducir el número de dependencias en el package.json no le viene nada mal a la mayoría de paquetes. Pero probablemente para la mayoría de estas funciones, no puedas escribirlas de tirón sin tener que entrar en Google a buscar en Stack Overflow, y a veces no tenemos tiempo ni de buscar en Stack Overflow.

Es aquí donde creo que las IAs de este estilo podrían tener potencial. No me hagas cambiar de ventana para buscar en internet cómo hacer X en Y, perder tiempo consultando la segunda respuesta porque la primera no aplica, luego la segunda pregunta porque la primera no contiene las respuesta que me interesa… En su lugar, deja que le diga al ordenador en palabras propias qué pretendo hacer y que me genere código sin levantar los dedos del teclado. O deja que automatice el código más aburrido y repetitivo de escribir para ahorrarme tiempo.

Existen razones por las cuales ni quiero pedir acceso a la beta de GitHub Copilot, pero de usarlo, se me ocurrirían casos de uso interesantes que de otro modo tendría que resolver perdiendo tiempo para escribir la función o buscando en internet, como por ejemplo:

  • Dado este array asociativo de objetos ({item1: { k1: v1, k2: v2 }, item2: { k1: v3, k2: v4 }}), fabrica un índice inverso a partir del campo k2 de cada item del array asociativo.
  • Fabrica un array con integers monotónicamente crecientes ([0, 1, 2, 3, 4...]). La IA generaría algo como Array(40).fill(0).map((_, i) => i).
  • Haz una función que valide un e-mail (¿te sabes la regex de memoria sin buscar en internet? ¿te sabes los mil millones de casos edge que tiene el RFC de las direcciones de e-mail?).

Parafraseándome a mí mismo en Twitter hace unos días,

Si programas en Java llevas pudiendo hacer clic para que el ordenador te genere los getters y los setters de tus clases desde hace décadas. Esto podría revalorizar el análisis y el diseño y dejar al ordenador que rellene specs. Imagina escribir un TDD y que el IDE lo rellene.

Trabajar en los procedimientos más complejos y reales y en la lógica de negocio que requiere intervención humana con el tiempo que gano cuando al pulsar un botón me rellena los métodos chorra tipo «buscar X en este array»? Lo compro. Y eso que no espero usar este producto.

@makigas

elfcat

Enlace

elfcat es un visualizador gráfico para inspeccionar las estructuras de datos y bytes internos de un binario ELF. Genera un archivo HTML que tiene metainformación y que con el ratón permite ver cada estructura de datos de forma individual. Está programado en Rust.

Esto me hubiese venido estupendamente hace un tiempo cuando me dedicaba en mis ratos libres a escribir parsers ELF y ese tipo de cosas como parte del sistema operativo homebrew que estaba construyendo y que sabe Dios cuándo retomaré.

Notas sobre el conjunto de Mandelbrot

Minientrada

Ayer cerré un stream en Twitch en el que intenté programar la típica representación gráfica del conjunto de Mandelbrot. No lo terminé porque se me alargó, pero lo continuaré. Dejo aquí algunas notas para cuando haga la segunda parte.

El conjunto de Mandelbrot es el conjunto de números complejos donde se cumple que la evolución de la serie definida por la función f(c, n) = f(c, n-1)^2 + c, siendo f(c, 0) = 0, no tiende al infinito. Por ejemplo, para c=1 se obtiene la serie 0,1,2,5,26…, no acotada, pero para c=-1 se obtiene la serie 0,-1,0,-1,…, que sí está acotada. (Por supuesto, c=1 y c=-1 son ejemplos muy simples, pero esta fórmula se usará con números con parte imaginaria como 0.2265+0.331i.)

Para facilitar las cosas, lo normal es asumir que si la magnitud del número complejo supera en algún punto de la serie el valor 4, entonces con seguridad no se acota. Como no podemos pedirle al ordenador precisión infinita, si después de un número máximo de iteraciones sigue sin tender al infinito, podemos asumir que sí se acota.

O sea, que al final en un programa de ordenador repetiremos la función hasta que se superen 50, 100, 1000 iteraciones (lo cual nos diría que está acotada), o hasta obtener algún valor con un absoluto mayor a 4, lo que nos deja interrumpir la ejecución asumiendo que no se acota. Cuantas más iteraciones apliquemos, más precisa será la evaluación, ya que puede ocurrir que una serie para un complejo tarde más tiempo en divergir, aunque también tomará más tiempo.

En cuanto a la clásica imagen del fractal generado a partir del conjunto de Mandelbrot, que seguramente muchos habremos visto alguna vez, lo que vemos es la representación en un sistema de coordenadas 2D del valor de esta función para todos los números complejos. El eje X representa la parte real del complejo y el eje Y, la parte imaginaria.

En el programa de ordenador generaríamos la imagen transformando del sistema de coordenadas de la imagen (por ejemplo píxeles del (0,0) al (640,480)) a una interpolación más aceptable en el rango de los complejos que vayamos a comprobar (como (-1,-1) a (1,1), aunque podríamos reducir el área para hacer zoom), y luego consultando si ese número complejo está en el conjunto o no. Si está en el conjunto, lo podemos representar de negro. Si no está en el conjunto, lo típico es crear algún tipo de paleta de colores para representar con un color diferente aquellos complejos que escapen antes al infinito de aquellos que escapan más tarde.

 Representación del conjunto de Mandelbrot
La clásica foto del conjunto de Mandelbrot tomada de Wikipedia.

¿Alguna vez dejamos de estar en guerra con el Excel?

Estado

¿Alguna vez dejamos de estar en guerra con el Excel? Piénsalo. En muchas ocasiones, tu trabajo como desarrollador consiste en crear software que resuelva problemas mejor que lo que puede hacerlo una hoja llena de fórmulas en Microsoft Excel.

(Corolario: un sistema informático nunca está completo hasta que no tiene un botón para descargar una snapshot de los datos cargados en él como CSV.)