Scripting con Fisinformático: introducción

¡Hola! Te doy la bienvenida a "Scripting con Fisinformático", una serie de posts dedicados a intentar enseñar algo que no se enseña en muchos sitios y que la mayoría hemos aprendido por nuestra cuenta: a pensar y razonar para scripting y programación, a convertir la idea que has tenido en código que un ordenador pueda entender y ejecutar.

Mirando manuales de scripting y programación y viendo lo que cuenta gente que sale de bootcamps de iniciación, veo que siempre se cubren los mismos temas: instrucciones, tipos de variable, control de ejecución, gestión de errores, estructuras de datos... Que son temas importantes y deben estudiarse para programar (y los estudiaremos, a nuestra manera), pero me da la sensación de que no se habla sobre cómo pasar de una idea a código que podamos ejecutar, o de cómo estructurar un proyecto para llegar hasta el final sin querer saltar por la ventana en un arrebato de frustración. Los programadores veteranos leerán esto y pensarán que muchas cosas son evidentes, o encontrarán errores que sólo se corrigen con experiencia, pero estos post están dirigidos a toda esa gente que programa, que sabe defenderse con un lenguaje pero que todavía no ve el alcance de lo que ha aprendido, porque ha aprendido a programar pero no a pensar en cómo programar.

Es decir, estos post no van a ser un compendio de instrucciones, sino de situaciones prácticas que podríamos resolver usando la fuerza bruta (hacerlo "a mano") pero que preferimos resolver con alguna automatización, porque esto es informática, la ingeniería de hacer que los ordenadores trabajen en nuestro lugar diciéndoles lo que deben hacer.

Pero para hablar con un ordenador hay que pensar como un ordenador, y los ordenadores piensan en términos de variables, funciones y lógica, matemáticas aplicadas, que hay que conocer un poco.

¡Un momento! No huyas todavía. Aquí no vamos a resolver ecuaciones ni a ver montañas de letras que fingen ser números, sino conceptos que usas en el día a día y que también se usan en matemáticas, a veces con el nombre un poco cambiado. Si ya has estudiado matemáticas seguramente ya sabrás de lo que hablo, pero en general serán cosas tan sencillas e intuitivas para las que casi siempre encontraremos un ejemplo de la vida cotidiana y dirás "pues no sabía que esto (que ya sabía) era por este motivo". A veces me tendré que poner más formal y contaros algo no tan intuitivo, pero seguiré la filosofía de mis profesores de la universidad: enseñar el concepto en general, dar una definición formal del mismo y pasar a un ejemplo práctico de esa definición.

Porque para explicarla bien habrá que poner ejemplos, y lo haré siempre con el mismo sistema: plantear el problema en términos sencillos, analizarlo para ver su solución, desarrollar la solución en pseudocódigo (en próximas entradas os cuento lo que es y por qué es importante) y luego pondré una solución del problema en Bash y PowerShell, dos lenguajes que conozco, que me gustan y que representan respectivamente dos de las formas de pensar más habituales en programación: lenguaje imperativo y lenguaje orientado a objetos. Veremos lo que esto significa más adelante.

Veremos también buenas prácticas, pero no porque sea fanático de ellas, sino como forma de evitar querer tirar el ordenador por la ventana cuando el proyecto crece un poco y empezamos a encontrar errores que no sabemos de dónde vienen. No pasa nada: nos ha pasado a todos muchas veces, y el que diga que no, miente o no se dedica a esto.

Programador después de dos horas viendo que
el error es "array[0] is out of bounds".
(Pronto entenderéis el chiste)

 

Pero ante todo veremos cómo escriptar y programar de forma pragmática: no voy a discutir sutilezas como qué lenguaje es mejor, más eficiente o más rápido, o si ciertas metodologías son mejores que otras. Queremos que las cosas funcionen y vamos a hacerlas funcionar, porque la mayor parte del tiempo (y scripters más veteranos te dirán lo mismo) una solución simple y chapucera que funciona es la mejor solución posible. Veremos por qué más adelante.

Por último, voy con una de esas "líneas rojas" que todos tenemos: si solucionas problemas con texto que una máquina interpreta para hacer cosas, eres programador. Y me da igual si es Bash, PowerShell, C/C++, Python, Java, HTML, YAML o Excel (sí, se puede programar "en Excel"). Cada lenguaje tiene sus sutilezas y sus ámbitos (que no voy a discutir, salvo que sean parte del problema), pero verás que la mayoría de lo que cuento aquí se podrá aplicar a cualquiera de ellos, porque estos post no irán de "la mejor manera de programar en X" sino de "pensar en cómo resolver un problema para programar", y voy a insistir mucho en esto, porque si has resuelto el problema, escribir el código ("picarlo") es cuestión de coger el manual y buscar lo que necesitas. Pero si no lo has resuelto antes, el código SIEMPRE va a ser un problema.

Aprende a pensar en cómo programar y podrás lidiar con el nuevo e
infalible lenguaje del iluminado/a de turno (Fuente: XKCD)

Así que espero que os guste.

La próxima entrada será introducción al pseudocódigo: vamos a aprender a traducir nuestro problema a algo que no sea del todo nuestro lenguaje ni tampoco el lenguaje del ordenador, y veremos trucos y preguntas que hacernos para conseguirlo, y lo haremos, como manda la tradición, con el "hola mundo" de Bash y Powershell.

Hasta entonces, cuidaos mucho, sed buena gente (que bastante miserable hay por ahí para encima serlo nosotros/as también) y pensad en lo que os gustaría desarrollar, porque igual podemos hacerlo por aquí.

¡Hasta pronto!