Programación con Sergio Gómez

Pues buenas, estamos otra vez en Codeadores, otro programa más. Esta vez vamos a hacerlo un poco diferente porque en lugar de centrarnos en un único lenguaje, tengo aquí conmigo a Sergio, Sergio Gómez, que yo lo conozco de mi época en la universidad. Era el operador, así lo conocíamos un poco entre todos los que estábamos en la universidad, con mucho cariño porque siempre nos atendía y nos daba soluciones a todos nuestros problemas. Y fue El primer enfoque, yo creo que fue la primera persona en la universidad que más sabía de Linux, y casi más incluso que los profesores, creemos recordar, la mayoría que te conocemos. Y bueno, si quieres presentarte un poco y hablar un poco de cómo te introdujiste tú en la informática.

Vale, bueno, pues me llamo Sergio Gómez. Y como has dicho, pues yo vengo de la misma universidad que tú, de la Universidad de Córdoba. Allí estudié informática, allí estuve trabajando 20 años de funcionario en el sitio informático también, hasta que hace la pandemia. No sé si está en la que veo o no, pero bueno, decidí hace 3 años irme al sector privado y ahora pues he pasado por un par de empresas. Ahora estoy en una empresa de Córdoba que se llama Audience. Y a informática entré casi, casi por vocación. Me compraron mis padres, vamos, se compraba mi hermano un ordenador y con él empecé a programar y vi que aquello me gustaba. Yo estaba tirando entre matemáticas e informática cuando era pequeño y al final ganó la informática. Y básicamente pues mi primer lenguaje en casa fue BASIC, así que, y realmente ya lenguajes así como en plan más serio no fue hasta la universidad. Que empezamos como todos, pues al menos en Córdoba, con C. Ese es mi bagaje, así que fue bastante vocacional la forma que entré a informática.

Yo recuerdo de las primeras veces que hablábamos de programación, que recuerdo incluso las conversaciones que teníamos eran principalmente de PHP. Entonces se puede decir que, bueno, aparte de C y BASIC ¿Los primeros lenguajes que empezaste a tocar podrían ser PHP como ese tercer lenguaje?

Es que antes de ese toqué posiblemente más, porque sí que es verdad que, bueno, sobre todo C fue el primer lenguaje, le guardo mucho cariño. Con C hice inclusive módulos de Apache en C, incluso para servicios informáticos, desde incluso como estudiante, porque cuando en mi promoción montamos una especie de preaula de software libre, igual da tiempo de hablar. Habla de programación informática. Hicimos una aplicación para gestionar el tiempo de los usos de las aplicaciones de servicios y tal, fue en C puro. Y sobre todo hacía mucho scripting porque, como tú has dicho, era como el operador. Era, o sea, antes de programador yo creo que he sido más administrador del sistema y ahí toqué mucho Perl al principio, pero ya programar aplicaciones para que las usara gente Bueno, pues aparte de estar en el servicio, estaba antes en el consejo de estudiantes y empecé a programar aplicaciones para el consejo de estudiantes y las hacía en PHP porque al final era lo más fácil de programar. Así que podemos decir que sí, que PHP ahí está de los primeros. Directamente con PHP me tiré muchos años trabajando porque incluso en el servicio era un lenguaje que se usaba bastante. Así que sí, me he tirado muchísimos años. Al principio con PHP a pelo, como se puede decir, y después con un framework que es Symfony. Ahí sí que hice bastantes aplicaciones, tanto para el consejo como para RITSI, que es la Asociación de Estudiantes de Informática a nivel nacional, como para el propio servicio. Hay una serie de aplicaciones dentro del servicio que se hicieron con Symfony.

Yo recuerdo que cuando empecé a utilizar Linux, la mayoría de scripting que había en el sistema operativo era todo Perl, que yo creo que también por eso, cuando estaba estudiando los ciclos formativos de administración de sistemas, tanto Rafa Castillo como Eloy hicieron énfasis en que aprendiésemos Perl. Pero sin embargo, Eloy estaba ahí dándole vueltas a la idea de introducirnos en Python porque él veía que cada vez más, incluso en distribuciones como Debian, Mandriva, bueno, Mandrake en aquel momento, estaban cambiando mucho scripting que antes se hacía en Perl, lo iban migrando poco a poco a Python. Incluso recuerdo el cambio que había en GIMP, que al principio todo estaba en Perl y después lo fueron cambiando a Python, y fue casi como una dinámica de abandonar Perl y saltar a Python. ¿Eso lo habéis visto también?

Sí, sí, porque yo creo que nos dio Eloy también, o sea, yo creo que las prácticas de Perl las empecé con Eloy. Eloy, bueno, un profesor aquí de Córdoba de de ciclo, sobre todo, estuvo un tiempo en la universidad. Y yo creo que sí, nos dio el mismo y empezamos con Perl por ahí, por ahí. Y los años de Python también fueron los mismos. Incluso Rafa Castillo cambió también. Al final, Rafa Castillo también empezó a dar Python porque al final Perl lo que tenía, lo que tiene para mi gusto, que si nos escucha mucha gente, el profesor JJ de Granada igual no está de acuerdo, ¿no? Creo que eres muy fan de Perl. Es que para mí resultaba difícil de mantener. O sea, un código de Perl al día siguiente se te olvidaba. Era muy complicado de mantener, la verdad. Entonces, era muy potente, sobre todo el tema de expresiones regulares, pero yo creo que era un lenguaje incómodo de aprender y bastante poco mantenible. Y por eso Python ahí se impuso mucho. Y también, bueno, Python, otro lenguaje que usamos mucho en el servicio para scripting. En el servicio informática tenemos, no sé si llegaste a verlo, un sistema de Linux remoto que se instala en todas las máquinas, ThingStation. No sé si llegaste a verlo. Vale, pues toda la parte de mantenimiento de ThingStation básicamente tiene una parte de Bash, de scripting con Bash, pero sobre todo tiene mucho Python para generación de imágenes y para la gestión del mantenimiento del catálogo, etcétera. Todo eso está hecho con scripting con Python porque la verdad que Python Para scripting que sea serio, el número 1. Para cosas más simples, bueno, con Bash te sirve, pero la potencia que tiene Bash para scripting, mantenimiento de sistemas y tal, la verdad es que a mí siempre me gustó bastante.

Y saliendo de, o sea, pues has dicho que estuviste 20 años en el servicio de informática y después te lanzaste ya a la empresa privada. ¿Cuáles son los lenguajes en los que has ido trabajando desde que llegaste a la empresa privada?

Bueno, en la empresa privada, el primero, o sea, he estado en 2 empresas. Entonces, la primera fue Python. Era una empresa de chatbots y todo el backend estaba hecho, una parte estaba hecha con Django y otra estaba hecha con Python, con un socket normal y corriente, no tenía nada especial. Y ahora estoy con JavaScript y Script en audio. Eso como lenguaje. Aparte, pues, la base de datos, etcétera. Entonces, distinto, ¿no? Pero el lenguaje de esos dos. Pero vamos, luego la UCO también, es decir, la UCO usaba Python, PHP, la Universidad de Córdoba. Y por mi cuenta también bastantes más lenguajes: Java, C#. De hecho, el trabajo fin de ingeniería técnica lo hice en C# con Mono. Como te dije antes, yo estoy aquí por vocación, me gusta programar. Entonces sale un lenguaje nuevo y si tengo tiempo me pongo a verlo, a ver si me gusta. Entonces los últimos que he visto era, por ejemplo, que el problema que no tengo tiempo, es Rust, un lenguaje que me interesa bastante, por ejemplo. No le hago problema a ningún lenguaje, pasa eso sí, ahora mismo el que más trabajo JavaScript y Script. Y el anterior Python. Lo que tengo el expertise más amplio ahora mismo son esos dos y PHP.

Entonces vamos, porque ese tipo de lenguajes siempre tienen no un nicho, pero siempre tienen un tipo de salida. Es decir, al principio decíamos que tu primera salida laboral fue con Python, que tenía Django, algo de socket, y Y el resto de salidas da la sensación de que van más o menos también en la misma línea, ¿no? De aplicaciones hacia la web, para software as a service.

Sí, ten en cuenta que al final muchas empresas empiezan con lenguajes interpretados, ya sea Python, JavaScript, PHP, etcétera, porque son lenguajes que para startups, para fundar la empresa, son lenguajes que desarrollan muy rápido. Java, C#, Rust, C++, etcétera, son lenguajes compilados y el desarrollo pues no es tan rápido, ¿no? Y al final lo que interesa es montar un prototipo lo antes posible. Con lo cual, si te vas al mercado, la mayoría de las empresas se mueven en estos lenguajes. En Ruby on Rails, se mueven en TypeScript, JavaScript, se mueven en Python con Django, se mueven en PHP con o con Symfony o con el otro, no me acuerdo qué hay de PHP ahora. Pero vamos, yo creo que el mercado de lenguajes interpretados tiene un trozo muy grande del pastel. Y los demás como Java y tal, dices, te lo encuentras en consultorías sobre todo, creo yo. Entonces depende del sector que te muevas te vas a encontrar unos lenguajes u otros.

Es curioso porque cuando estuve hablando con Chema de Genially, él me dijo que había empezado todo el proyecto y todo el producto mínimo viable Lo había hecho directamente en C# y después ya cuando necesitó escalar vio que las licencias eran caras y entonces ya cambió a JavaScript.

Yo escuché, porque yo fui a una charla suya hace tiempo en Cofera, y lo contaba. Y yo creo que él era la excepción. O sea, una startup montada con lenguajes tipo C# y tal, yo no lo he escuchado muchas veces. Las hay, está Overflow, que yo sepa funciona con C# también. Ya ves tú cómo va. Pero lo normal, lo normal no es. Pero al final es que te va, o sea, yo creo que si aprendes cualquier lenguaje vas a encontrar salida. Lo vas a encontrar con COBOL. Al final te aprendes el lenguaje y vas a encontrar salida. En algún lado alguien lo está usando. Por eso, porque bueno, porque el que funda la empresa monta, sabe ese lenguaje, porque creo que el Chema venía también de consultoría o algo así. Venía de Madrid a trabajar, no sé exactamente dónde trabajaba. Y el lenguaje de conocimiento lo montó con eso. Entonces, pues ya está. Si cuando lo monta el fundador, pues al final tienes que coger programadores de ese lenguaje y a alguien vas a encontrar. Pero te digo, eso yo creo que es lo raro. Yo la verdad es que se lo he escuchado a él y a poca gente más.

En sí, si tuvieses, en la empresa que trabajas ahora mismo, te dijesen, oye, vamos a empezar un nuevo proyecto, dependiendo de qué tipo de proyecto fuese, ¿qué lenguaje utilizarías o con cuál te estarías más cómodo para empezar? Un proyecto así desde cero?

No te voy a decir Rust porque igual estás esperando. No te voy a decir Rust, pero porque a lo mejor va a ser la oportunidad de hacer algo en Rust y tal, y en la otra empresa anterior y tal, y no lo he hecho por el simple motivo de que si tú te vas de la empresa, eso, ¿quién lo mantiene? No es fácil encontrar programadores de Rust. Yo creo que al final los lenguajes, salvo que sea una cosa muy específica que requiera una velocidad impresionante, baja tiempo de respuesta y tal, yo creo que los lenguajes casi quedan igual. Aquí internamente en Audient, yo no estoy en ese equipo, pero también tienen proyectos con Scala, por ejemplo, porque bueno, otro lenguaje que se usa por la parte de... porque es un lenguaje funcional y a lo mejor pega más para el tipo de aplicación que es. Ya te digo, me gustaría programar algo en Rust, pero porque la empresa ya lo tenga Más que de proponer yo hacerlo dentro. Por eso digo, porque al final tienes una empresa que diga que apuesto por Rust porque yo voy a buscar programadores de Rust. Me gustaría, pero si no, ya te digo, no tengo ningún lenguaje así que diga que motive, hostia, aparte de ese, de decir bueno, me cambio. Yo creo que PHP está un poco vilipendiado, tiene mala fama, pero no es tan malo como la gente piensa. Sigue siendo un lenguaje muy decente, sobre todo a partir de la versión 8. Se lo curraron muchísimo. A mí me sigue pareciendo un lenguaje muy— más que lenguaje, el framework de Symfony, lo que me motiva más que el lenguaje, porque el lenguaje al final— pero el framework sí es muy potente, está muy bien hecho. En Python lo que no me gusta mucho es Django, pero por ejemplo FastAPI me parece muy buen framework para hacer aplicaciones con Python. Y en TypeScript, o sea, en JavaScript, el framework de los que más me gustan, Nest con S y Nuxt con X. Pero no solamente también el lenguaje, un poco la herramienta con la que uses. Porque decir, lo programaba a pelo no es conveniente, porque al final hay problemas de seguridad que los frameworks te los solucionan. Y tú vas a— o sea, que no solamente el lenguaje, tienes que acompañarlo un poco del framework que vayas a usar. Entonces también el hecho de que el framework esté bien hecho, bien documentado y te ayude un poco a programar también motiva. Pero te digo que no, así a priori, cualquier lenguaje de esos me importaría volver.

Y la moda, bueno, moda, El cambio que hubo hace tiempo en el que incluso Java, la versión 8 recuerdo, y a partir de la 8, Java, JavaScript, esos lenguajes que han sido de siempre puramente imperativos han ido adoptando poco a poco más el sabor funcional. ¿Has tenido la oportunidad de—? Porque yo recuerdo que en la universidad nos daban bastante caña con Eclipse y Scheme. Y hay otros lenguajes como Clojure que se parece también mucho a Scheme. ¿No te ha dado por probar algo como Clojure, Haskell o las formas más funcionales de estos lenguajes?

Cuando es que la verdad es que estoy tan acostumbrado a programar de la otra manera que, y como esto lo que radica es cambiar tu forma de pensar, sí que he metido cosas funcionales tipo mapas, filtros y tal. O sea, pequeña escala dentro de JavaScript tiene algo de funcional, Rust también lo tiene. Entonces por ahí cuando he podido lo he metido. Pero sí que es verdad que por ejemplo Scala, que es más funcional, tenía curiosidad, Scala a lo mejor no me importaría meterme, pero sí que es verdad que cambiar totalmente la forma de pensar y muchas veces no querer, es decir, es que en el trabajo no sale porque tampoco hay mucha oferta con funcional. Y normalmente yo los lenguajes los suelo aprender con side projects y tampoco me ha salido así una idea de, venga, voy a hacerlo con esto y tal. Entonces sí que me ha quedado, por ejemplo, Scala me ha quedado porque lo uso en entrenamiento y porque ya de antemano ya escuché bastante de Scala y tal, me quedó con las ganas. Y al final pues le digo, la parte funcional, cuando he tocado así, o la parte funcional que tienen los lenguajes no funcionales como Rust, JavaScript, pero eso, la parte de mapping Y tal, a poca escala. No he tenido oportunidad de hacer un side project o algo que me ayude a aprender, porque al final sí puedes coger un libro. De hecho, creo que los tuyos los tengo comprados de Haskell, y al final te lees el manual, vale, lo haces, pero después no haces nada con ellos y te olvidas a los 2 días. Entonces creo que va a ser una falta más de encontrar algo donde aplicarlo que el hecho de al final de de no querer.

Yo recuerdo que del último proyecto que vi en Java fue el año pasado, curiosamente dentro de la empresa, y habían chavales que me empezó a enseñar de mira, es que tengo esto de proyecto hecho, y no lo reconocía porque había introducido tantas cosas funcionales. Decía, pero ¿cuándo Java se convirtió en esto? Y me sorprendió bastante. E incluso en Python hay mucha gente que no programa de forma, bueno, que no es que no programe, sino que prefiere el enfoque funcional, o sea, las listas de comprensión, el utilizar map, filter y otro tipo de técnicas en lugar del típico bucle para procesar datos. Al final yo creo que son las diferencias principales entre uno y otro.

De hecho, la parte funcional, JavaScript también es muy típico. Map y filter antes que for. Al final yo creo que es más legible también que ponerte un for ahí y luego hacer una variable para ir metiendo los datos en vez de hacer el map y tal. Y otro patrón que están poniendo mucho ahora, que ya existía de antes, pero yo creo que ha sido Russell que lo ha puesto de moda, el patrón maybe-either, ¿no? En funcional, que en Russell llaman option y result. Pero que al final el header y el main, que al final eso, porque al final te ayuda a decir la salida la concateno con otra cosa, que hago un mapa con otra cosa, que no sé cuánto. Yo creo que también se ha puesto porque en Java crean librerías al respecto, en Python también sale una librería al respecto. La he usado las dos, o sea que, pero sí es verdad que se nota que los lenguajes no están preparados para ese tipo de de patrón y visualmente no queda tan estético. Pero sí, yo creo que hay un poquillo de gusto por lo funcional. Yo creo que al final lo que faltan pues igual son tiempo y recursos, no sabría decirte. Pero sí, en general te cuenta que la gente pues tiene interés, al menos el patrón este de Result, que da igual que lo queramos llamar. De hecho, la gente de Codely tiene muchas charlas ya al respecto también. Entonces, sí, yo creo que por ahí hay un gustillo en torno a la gente, al menos a evitar usar excepciones.

Yo he escuchado que ese patrón lo utilizan para intentar evitar el null. No recuerdo ahora mismo, pero recuerdo una charla en el que el creador, el primero que implementó el null en los lenguajes de programación, dijo que lo consideraba su error del millón de dólares. Entonces, este patrón se supone que está ahí para intentar no utilizar tanto null y utilizar algo diferente.

Sí, sí, de hecho el hombre se arrepiente un montón por inventarse el null. Es como las excepciones, al final no sabes nunca la intención de la función, si la función te devuelve null porque está mal o porque realmente quería devolver null. Entonces el patrón al final optio es más explícito, te devuelve algo o te devuelve nada, pero te lo digo explícitamente. Iba por ahí. Y aparte, pues te quitas también el tema de decepciones porque te devuelvo algo o te devuelvo un error. O sea, esto ya para empezar ya tienes tipado, ya tienes la intención del error que te devuelve la aplicación, que también pues al final estamos intentando. O sea, podemos hablar también del tema de que todos los lenguajes funcionales, perdón, todos los lenguajes interpretados se están pasando a tipados, están metiendo todo el mundo tipos, ¿no? Ese otro error que hemos pasado todo, de no querer tipos a que ahora queremos tipos en todos lados. No me he dado cuenta de la cantidad de errores. Y las excepciones pasa un poco eso, no tienes información del tipo de excepción que te está llegando. Entonces, este tipo de patrones yo creo que viene a forzar a hacer un poco el tipado.

Habías dicho que estabas aprendiendo Rust, o que ya lo estabas empezando a utilizar. ¿Qué lenguaje está ¿Tienes ahora mismo en plan de quiero aprender estos lenguajes o estoy aprendiendo estos lenguajes de programación?

Pues mira, nunca he usado Go, nunca he tenido tiempo de Go, pero es que para aprender Go prefiero meter más tiempo a Rust porque al final Rust lo he usado en el app de 2Code, o sea, lo he usado para hacer los apps hasta el día que dije este día ya no sigo más porque me Porque me está matando este hombre. Pero lo he usado solamente para eso, o sea, porque al final no tiene ningún proyecto donde a Rust le saques partido, porque no vas a hacer una aplicación web tú solo para Rust. Vas a usarlo para microservicios y tal, pero tampoco tiene así como— Entonces, y luego hice una encuesta justo en Twitter para ver si la gente me motivaba a usar un lenguaje para ver el código este año, y se quedó empate Rust con OCaml. O Camera, el lenguaje, no me acuerdo el nombre, pues saca empate. Así que, pero igual lo intento con ese porque también tiene así como un poco, la gente está hablando bastante bien de él y tengo todavía un mes entero para verme un tutorial o algo, a ver si me convence. Y si no, pues volveremos a intentarlo con RAG este año. Pero sí, ahora mismo ese lenguaje. Y también estoy viendo algo, pero no me llama mucho la atención al final, el lenguaje que sacó Google para reemplazar a A C, de todas formas, también sacar su propio lenguaje. Pero todos los tooling y tal, pero no me acaba de convencer. Estando Rust, no le acabo de ver sentido a sacar otro lenguaje. Y además con la fama que tiene Google de dejar las cosas a medias luego.

Bueno, Google tiene de momento Dart y Go. Y bueno, Carbón, yo le he ido siguiendo un poco la estela. Y lo único que he visto es que cada vez lo retrasan más. Al principio decían que iban a sacarlo en 2024, después llegando al principio de 2024 dijeron 2025, y a mediados de este año ya han dicho que 2026 en adelante. Así que tampoco se sabe exactamente cuándo saldrá.

Bueno, el último drama ha sido que Flutter ha hecho un fork, no sé si lo sabes. Está Google como para fiarte mucho, la verdad. No sé, yo ahora mismo eso, quiero mirarme OCaml porque sí que he escuchado bastantes cosas bien. Y este mes miraré algo y si me convence pues intentaré hacer el App VegO de este año con OCaml. Y si no, lo intentaré con Rust. Y te digo, los 10-12 primeros días, que no suele durar mucho más, la verdad.

Curioso de OCaml, tenía un compañero en Estocolmo cuando estuve allí que le encantaba ese lenguaje de programación. Y estaba siguiendo también a otro creador de lenguajes que se llama Glimpse. Estuve siguiendo bastante porque Grimm trabaja transcompilando a JavaScript y a Erlang. Entonces estuve hablando con el creador y al ver cómo hacía un lenguaje de tipos, pero los tipos eran como lo que hemos comentado, de ahora dice esto puede retornar OK y un valor o error y un valor. Entonces decía, este tipo de tipo, ¿qué es? Me dio la curiosidad y ella me dijo, no, es que esto está basado en OCaml, que tienen este tipo de conjuntos de tipos. Entonces tú defines el conjunto de tipos y los asignas para poder retornarlos, y entonces te permite generar un conjunto más rico de tipos a la hora de programar cada función. Estuve, creo que fue hace 2 años, haciendo el Advent of Code precisamente con ese lenguaje para probarlo, y me pareció fascinante. Por lo que si sacaron los tipos de OCaml, te recomiendo mucho echarle un vistazo a ese lenguaje porque te va a fascinar.

Pues mira, justo he buscado encuestas, le puse Rust, Fig, Ruby, OCaml. Y se quedó empate, Rusi y Gokal. Así que tú vas a hacer el voto de desempate. Y mira, este mes me miraré algún tutorial por ahí y lo intentaré. Ya te digo, lo que te decía antes, a mí me gusta programar. El lenguaje creo que un poco lo de menos. A mí me divierte programar. Entonces, si el lenguaje es bueno y te entretiene, pues no tengo ningún problema en programar, aunque sea para nada, para entretenerme. O sea, porque luego no lo va, entre comillas, no lo va a usar en ningún sitio, que tampoco es verdad. Yo lo que aprendí de Rust con el tema de este patrón, este result y tal, lo he aplicado después en otros sitios. Al final aplicas cosas que aprendes de otro lenguaje o en otro framework. Así que sí, le echaré un ojillo.

Y otra cosa que te quería preguntar, porque ahora que estábamos hablando de lo del aprendizaje del lenguaje, ¿cómo afrontas tú el tomar un lenguaje así como OCaml, que es completamente nuevo, y decir oye, pues me voy a meter en este lenguaje y voy a aprenderlo? O sea, ¿qué pasos sueles tú seguir?

Yo tengo un side project que es como el que siempre hago. O sea, yo quiero aprender el lenguaje, tengo una idea en concreto y es la que implemento siempre, que fue la primera aplicación que hice para el Consejo de Estudiantes, que era una aplicación que era para gestionar las actividades del consejo. Era una página web que la gente se logueaba y se apuntaba a una charla o lo que sea. Era un gestor de actividades, tampoco Una bien bright, pero muy simplito. Pero ya un problema que tengo tan dominado que no tengo que pensar ni la interfaz, ni tengo que pensar modelo de datos, ni tengo que pensar nada, sino que esa idea la cojo e implemento en el lenguaje que sea. Y normalmente eso es lo que suelo hacer. Y si no, intento, te digo, buscar algún problema y, o sea, un side project e implementarlo con el lenguaje ese. Ya no estoy en el consejo, entonces ya no hago esas cosas al consejo. Pero sí estoy en el aula de software libre y entonces hay aplicaciones que he hecho en Next, por ejemplo, para el aula, porque primero le viene bien al aula y me viene bien a mí porque así aprendo ese framework y luego lo puedo impartir a los chavales. Cuando hablas de aula, porque la gente no sabrá, el aula de software libre de la Universidad de Córdoba, que es un grupo de estudiantes que está en la universidad. Por ahí, por ejemplo, hice una aplicación para gestionar la biblioteca, la biblioteca de del libro que tiene el aula, que tiene 50 libros o así, y los préstamos y tal, pues le dicen Next. Bueno, así me ponía al día con Next y tal, y así aprendía Next. Porque al final, vale, lo de siempre, te lees el manual, está muy bien explicado, pero a los días se te olvida. Así que sí, intento siempre, bueno, pues si tengo algún problemilla para ayudar a quien sea, pues aprovecho y lo hago. Y si no, tengo ese, digamos, ese side project como de plantilla para aplicarlo a cualquier cosa. También tengo otra, otro, cuando quiero aprender un poco más, no sé, cómo aplicar patrones a un proyecto, tengo otro proyecto que se llama IAM, Identity and Access Management, que es un gestor de identidad que guarda usuarios, cosas como que modelo de datos me lo conozco, no tiene front, es puro back. Pues lo uso para aprender. Con Nest aprendí pues haciendo ese proyecto, por ejemplo. Con Python, con FastAPI, también lo usé ese proyecto para aprender FastAPI. Cosas así. Entonces tengo un par de proyectos. Si quiero hacer solo backend o full stack, pues uso uno u otro.

Entonces la recomendación que daría a alguien, o sea, en principio la recomendación sería si te llega alguien que no sabe absolutamente nada de programación y te pregunta por cómo dar los primeros pasos y en qué lenguaje, ¿qué le dirías?

A ver, si no sabe nada, nada, pues tampoco sé si programar algo. Yo creo que si no sabe nada, entonces sí, vaya a lo clásico, aprender primero un lenguaje, los bucles, la sintaxis del lenguaje y los patrones básicos de diseño, porque al menos una base la tiene que tener. Si ya sabes un lenguaje y quieres aprender otro distinto, ahí sí yo soy más fan del learning by doing, que aprende haciendo algo. Si no tienes ninguna idea, pues copia una de una aplicación que uses todos los días, entonces que tú conozcas. No tienes que pensar ni cómo va a ser la interfaz ni cómo salen los datos, ya lo sabes porque lo ves todos los días. No la hagas entera, intenta ver lo más pequeñito que tú puedas que se vea algo, porque si no vas a tardar un montón de tiempo y te va a decepcionar. O sea, intenta coger de esa aplicación que ya conoces lo más básico y la implementas con ese lenguaje. Y si te mola ya el lenguaje y estás aprendiendo, pues le implementas otra cosa más. Pero eso sí, ya conoce el lenguaje. Si no sabes absolutamente nada, yo creo que mejor que cojas un curso que te vaya introduciendo los conceptos uno a uno, porque si no, yo creo que te vas a perder.

¿Y qué lenguaje sería el que tú recomendarías para alguien que comienza?

Si no ha estudiado informática y se quiere meter, Python, la verdad. ¿Para qué nos vamos a engañar? Porque si no te quieres meter con tipos, pues no te metas y programas Python tal cual. No te metes en los problemas de llaves. Al no tener las llaves, pues ya te obliga a tener la indentación, con lo cual código más legible. Tiene un montón de documentación, un montón de librerías, un montón de cosas, un montón de tutoriales. Yo creo, si no te metes en la carrera de informática y tal, y vienes de fuera y quieres aprender algo, yo creo que Python es el más accesible en general. Si ya estabas en informática y ya tienes la base de programación, ahí también un poco depende de dónde te quieras meter. No voy a decir PHP porque es la broma de todo el mundo, pero sí que es verdad que el lenguaje al final está cayendo un poco en desuso. Pero las cosas como son, ahora creo que el mercado está alrededor de JavaScript, entonces yo creo que ese lenguaje te va a dar, las cosas como son, si te metes en informática porque quieres trabajar y ganarte la vida, pues al final va a ser el lenguaje que que te va a dar salida bastante rápido. Y una vez que sepas un lenguaje, el segundo te va a costar menos y el tercero menos todavía, salvo los funcionales, que eso es otra historia distinta. Pero el resto de lenguajes, al final aprendes el lenguaje y la sintaxis, tienes que aprender toda la sintaxis nueva y poco más, porque al final es pelearte con el API de las frameworks y tal. Así que depende, te digo, si eres un neófito de la programación, yo le recomendaría Python, y si no Y porque está en informática, tienen una carrera, y Python tiene mucha salida, Python tiene bastante salida también, pero JavaScript tiene más. Y ahí recomendaría JavaScript.

Has dicho que en tu último trabajo empezaste con JavaScript y TypeScript, pero ¿ya tenías experiencia en esos lenguajes o tuviste que empezar de cero? Yo te digo, sí.

Como tocaba de todo, pues no tenía problema. Yo ya sabía TypeScript y JavaScript. De hecho, en el aula de software libre damos un curso de arquitectura de software y lo empecé los primeros años, lo empecé a dar con Symfony. Pero yo me dije, ¿dónde voy con todo? ¿Dónde voy enseñando Symfony? Porque al final, al final, a ver, aprendo un montón de patrones, pero bueno, al final también quiere enseñar algo que después le sea útil y lo pasé Lo pasé a Nest y ahora lo estoy pasando a Next con X un poco. Entonces empecé a dar talleres de JavaScript y ya sabía también, porque al final tiene, primero porque daba mucho backend y poco frontend, y ya estaba empezando a meter frontend y al final con Nest con X lo tienes todo frontend y backend y lo juegas todo de golpe y lo que es las cosas concisas. Al final por utilidad. Pero ya sabían también, si es que JavaScript hay que saber, porque si quieres hacer aplicaciones web algo tienes que saber JavaScript.

Bueno, y esa tendencia que hay de intentar ocultar JavaScript detrás de otro lenguaje que transpile a JavaScript, TypeScript no deja de ser algo que transpila JavaScript, ¿no?

Bueno, pero no fue el primero que lo hizo, está CoffeeScript. Pues CoffeeScript era lo mismo, era un lenguaje que hacía la sintaxis de JavaScript más amigable y transpilaba JavaScript porque al final, pero estamos en las mismas. Yo creo que el problema de JavaScript es que no tiene tipos y al final es que te hace falta tipo. Yo creo que la falta de tipo Por mucho que diga el inventor de Ruby on Rails que está en contra de los tipos, creo yo, es que te quita un montón de, te quita un montón de problemas, te quita un montón de bugs, hace el código más legible para la gente nueva que entra, más seguridad. Yo creo que no tipar, yo creo que el lenguaje no tipado fue un error de los primeros años por la dificultad que implicaba C, C++ y esas cosas.

Bueno, incluso no recuerdo si Rust lo tiene, pero sí recuerdo que Go, o sea, tienes que utilizar tipos, pues son lenguajes con tipos. Pero en el caso de Go y otros lenguajes, lo hay que son tipos inferidos, es decir, que no hace falta definirlo en todos y cada uno de los sitios, solo cuando el compilador no es capaz de deducir qué tipo estás utilizando. Pero obviamente, si pones a es igual a 5 ahí el compilador sabe que es un entero y no hace falta explicitarlo. Simplemente en las funciones donde van los tipos y otros sitios donde es imposible que el compilador lo sepa, pues entonces ya ahí sí tienes que ponerlo. Ah, con los tipos básicos no tienes problemas.

El problema es que no solamente manejas tipos básicos, tienes diccionarios, ¿no? Y ahí no es a lo que te llega. De eso, mientras la empresa, el fallo que teníamos, el mayor problema que teníamos Es que era una aplicación Python que se hizo con la versión 2 al principio, o sea, no tenía nada de tipo. Y entonces los datos, o sea, los argumentos eran todos mutables, todo diccionario, paseaba para abajo y tú no tienes ni idea de lo que llegaba a aquella función y los datos estaban, no estaban, y te digo, y mutando argumentos, o sea, todas las malas prácticas que puede dar una startup que empezó Y con ese código, al final, esas cosas te encuentras en todos lados. Pero yo creo que no tener, no empezar con tipos es una deuda que te va a pasar factura más tarde o más temprano, a la larga. Así que yo no recomendaría a nadie no usar tipos para nada. Por eso, porque a la larga te vas a arrepentir. Yo, vamos, yo todos los proyectos no tengo tipos, a la final te vas a arrepentir.

Y la verdad es que yo creo que todos hemos experimentado eso en alguna mayor o menor medida. E incluso en muchos lenguajes que tienen tipos yo me he encontrado gente que intenta saltárselos con el típico void* object o cosas así, que ya intenta averiguar fórmulas para saltarse los tipos porque no les gustan.

Es una de las cosas por las que me gusta Rust, porque es como un puzzle, te obliga tanto a pensar el tipado Porque ahora te acostumbras a que programas en este lenguaje interpretado, al final tipado, pues estáis sintiendo no sé cuánto, y al final es el ítem que te va como metiendo y al final se traga lo que le eches, no sé qué. Pero en Rust tienes que pensar, bueno, que esto si lo paso luego lo tengo, no lo tengo, por el préstamo, por el préstamo, el préstamo de variable, no sé cuánto. Esto pues ustedes después, ¿cómo lo tengo para que lo tengo que volver para atrás? No sé qué, es como la antigua santa que tenía una vez para aprobar y tenía que compilar a la primera, como en el principio de la carrera, no tengo tiempo, tengo una hora para el examen y yo tengo que sacar a la primera, no puedo hacer pruebas. Pues un poco de Rust es decir que programar se convierte en un puzzle, como un reto, y eso es lo que me mola de Rust, que las cosas no son tan sencillas y el tipado tiene que funcionar porque si no compila Si no está bien, no compila, y no compila.

Sí, yo creo que Rust es de estos tipos de lenguajes que tienen una forma de hacer las cosas y tienes que encajar tu idea en esa forma. Hay otros lenguajes como Elm o Erlang, por ejemplo, que tienen una forma de hacer las cosas, y si no lo sabes encajarlo bien o no sabes cómo idear lo que quieres hacer en ese lenguaje, en esa forma, ya pues pierdes, empieza a darte problemas el compilador, empieza a no funcionar lo que quieres implementar. Supongo que puede ser ese problema, lo estaba hablando ayer con otra persona de la implementación en Rust, que decía el modelo de memoria de Rust funciona de una forma específica. Entonces, si tú quieres implementar algo que tiene una serie de punteros cruzados y demás, pues el compilador te va a decir, no, así no. Y entonces te va a ir poco a poco sugiriendo que utilices los handlers, que utilices otra serie de mecanismos, y entonces cambiar la idea a una forma que obviamente es más segura y que seguramente tendrías que haberlo pensado así desde el principio. Y que probablemente después de utilizar durante muchos años Rust, pues al final te termina cambiando la configuración de tu forma de pensar para llegar siempre a ese tipo de soluciones porque ya sabes cómo funciona o cuáles son los modelos de memoria más seguros, o cómo son los modelos de memoria seguros que utiliza Rust. Que quizás sea eso, el encajar dentro del lenguaje el compilador y los tipos, lo que tú quieres hacer para que no te dé problemas y que sea lo que los diseñadores de ese lenguaje querían que fuese, cómo se hace esa solución.

Eso me interesa, ese sentido, por eso, porque como tienes que pensar mucho lo que estás haciendo, que no es simplemente programar y a ver qué pasa, no, el tema es así que, pues nada, eso. Pero vamos, yo creo que este año va a ganar OCAL, a ver qué tal se comporta.

Y el mercado laboral, ¿cómo lo ves tú a día de hoy? Sabes, ya hemos hablado de que, por ejemplo, estabas comentando de que en JavaScript hay muchas más ofertas de trabajo. Pero, ¿cuáles son los lenguajes de programación que tú dirías de si quieres trabajar seguro, ve por esto? Pues no sé decirte ahora.

La verdad es que parece que está el mercado un poco parado por el tema de, bueno, de que no se sabe un poco si hay crisis, si hay burbuja y tal. Parece de todas maneras que se está recuperando otra vez. Pero es lo que te he dicho antes, yo creo que hay salida para cualquier lenguaje. Yo digo, hay salida hasta para COBOL. Entonces yo creo que si te vas a pasar 8 horas programando en un lenguaje, que sea algo que te guste. O sea, aprende el lenguaje que te guste. Vete, también es lo que he dicho antes, yo creo que lenguajes también son todos iguales más o menos. Lo que te tiene que motivar mucho es el framework, porque más que con el lenguaje te vas a pelear con el framework que estés usando. Si es con Java, pues creo que la mayoría usa Spring. Si es con Python, la mayoría que usa Django, etcétera, etcétera. O sea, que no solamente el lenguaje en sí, que al final vas a probar con un framework, que sea algo que te diga, hostia, pues a mí este framework me gusta, ¿no? Las herramientas que tengo de este framework me facilitan la vida no sé cuánto. Tengo la forma de debuggear y hacer testing, es fácil. Porque eso también es muy importante, que la gente no lo tiene en cuenta. Puedas hacer testing con el framework, te permita y tenga herramientas de testing de forma fácil, de forma fácil, también una cosa a considerar. Entonces yo miraría ese tipo de cosas y cuando tengas algo que te guste y tal, dedícate, ponte 100% y es verdad que hay empresas que están buscando gente. O sea, que en ese sentido no, y si no, y si tienes que aprenderte un lenguaje, lo aprendes. Digo que yo te digo, vengo de Python, En la universidad estaba el último día PHP y ahora estoy con TypeScript. Y si mañana me llama una empresa y quieren a alguien de Rust, me cambio. Si pagan bien. O sea, que yo con lenguaje doy de menos, pero lo importante es pasártelo bien con el framework o con lo que estés haciendo.

Yo lo que veo es que hay una barrera de entrada porque si yo ahora, por ejemplo, digo, oye, yo quiero utilizar Rust o Haskell porque he visto que hay ofertas de trabajo que piden estos lenguajes de programación. El problema que tendría ahora es que incluso siendo senior en otros lenguajes de programación que utilizo a diario, en estos lenguajes de programación no podría considerarme yo a mí mismo senior. Entonces tengo esa pequeña barrera de que si voy a dar entrevistas y me preguntan cuántos años llevas programando con este lenguaje, pues tendría que decir, pues bueno, no mucho. Es que existen lenguajes súper especiales.

Haskell, porque es funcional, yo creo que más que lenguaje es forma de pensar, más que lenguaje en sí. Rust y C++, porque son compilados, son muy estrictos con el tipo, tiene unos tipados muy concretos y tal, que son un poco más complicados de la cuenta. Pero yo creo que esa mentalidad la tenemos los seniors por el síndrome del impostor, porque tú ya sabes lo que tú sabes en un lenguaje y sabes que en otro no llega. Pero luego te vas por ahí y sabes cómo está el mercado, que hay gente que a lo mejor es serio porque lleva muchos años, pero no es serio porque este programa es como un serio hablando de calidad de programación. Yo creo que por ahí un poquito de síndrome de impostor tenemos todos, contra más años más grande lo tenemos. Pero yo creo, vamos, mi experiencia dice que cuando cambias tu lenguaje, pues sí, tardas 2 o 3 meses en cogerle tranquilo el lenguaje, pero da igual, el lenguaje de cualquier empresa donde te metas te va a durar de 3 a 6 meses hasta que cojan la plataforma. Entonces tú ahí te tienes que vender como diciendo, mira, este lenguaje, no soy senior en sentido, pero sí senior programando porque llevo X años. Y yo, si tiene una persona que resuelva problemas, yo resuelvo problemas. El lenguaje, pues mira, tardé un poco más, pero al final aprenderé como he aprendido los demás. Es verdad que muchos recruiters no lo entienden, o mucha gente no lo entiende. Pero es que la realidad es así. O sea, yo, es decir, cuando tiene oportunidad de fichar gente, he cogido gente que no sabía Python, la otra empresa, la de otra, porque la otra la pagué. Y yo cogí, yo fiché a gente que no sabía Python, lo aprendieron en 2 semanas. Pero yo no quería porque no supieran Python, yo lo quería porque sabían programar bien. Python aprendieron a las 2 semanas y a las 2 semanas programaban mejor que los que tenía yo dentro y enseñaba a los que tenía dentro. Por eso te digo que tenemos un poco de síndrome de impostor en ese sentido. Si tú programas bien un lenguaje, en el otro va a ser eso, cuestión de un mes, dos meses, que es igual porque es el onboarding que vas a tener para la aplicación. Tampoco conoces cómo funciona la aplicación.

Y ya que estamos hablando de la parte funcional, voy a saltar al otro extremo. ¿Cómo ves la orientación a objetos? Porque ha habido mucha polémica de que si era un desastre del billón de dólares de Alankai. Nosotros lo vimos con el canal este de Programando Otra Historia. Hay mucha gente que ha tomado eso de la programación orientada a objetos como que es un error. Y yo no lo veo en sí como un error, sino como que orientarlo todo a objetos en sí es un error, pero tener orientación a objetos de per se no. ¿Tú cómo lo ves?

Mi CTO de Audience hace rato les dio una charla y habla del tema este como diciendo No es este tema, pero parecido. Cuando tienes un martillo, todo te parece un clavo. Entonces, el problema de la programación orientada a objetos es que como la gente sabe programar objetos, pues los tiene que usar por narices. Porque esto es una programación, vale. Pues no, tienes que usar objetos cuando corresponda. Es decir, si no vas a hacer una interacción con terceros, no vas a hacer una librería, tienes muy poca oportunidad de usar objetos porque prácticamente casi no va a extender nada. De hecho, en PHP hay una discusión de ese comportamiento de las clases, eso en el grupo de élite de PHP o de Symfony, si todas las clases tenían que ser final por defecto, porque por defecto no son final, son extensibles. Y lo que decían es que tiene que ser al contrario, el comportamiento tiene que ser final y tienes que tener una buena razón para que no lo sean, porque al final, al final lo que El problema no es la herramienta en sí, es mal uso también. Porque bueno, pues tú sabes que la carrera, no sé si en todas partes, pero el típico ejemplo de programación de mesa y silla y cuadrado, círculo, pues claro, te enseña una idea muy mala de lo que es programación de objetos. Te piensas que es herencia. Yo creo que el problema de programación de objetos no es la programación en sí, sino que se usaba mal. Entonces, pero yo no sé, por lo demás, bien usada no hay ningún problema.

Te iba a preguntar, porque últimamente está la polémica esa de si ChatGPT le va a quitar el trabajo de programación a los programadores. Quería saber también tu opinión sobre eso.

Yo creo que el problema de ChatGPT es que le va a hacer mucho daño a los juniors. Más que a los seniors, porque al final no deja de ser otra herramienta que te puede ayudar a que si la pregunta la haces bien te responda. Pero claro, para hacer la pregunta bien tienes que saber qué preguntar. Entonces un senior sí va a saber preguntar, pero un junior no, ni va a saber de qué preguntar ni va a entender si la respuesta es correcta o no. Y el problema de eso Además de que es que el junior no está haciendo ningún proceso de aprendizaje, está preguntando, copiando y pegando. Yo, por ejemplo, de las cosas que más he aprendido es por cuando tenía un bug que no lo encontraba, es irme al código fuente de, como gracias al software libre, por eso soy muy defensor del software libre, irme al código fuente de la librería, de lo que sea, a saber por qué se comportaba eso de esa manera y tenía ese problema. Y eso es lo que hacer y poner puntos de depuración en la librería del lenguaje para ver qué estaba pasando. Eso me ha enseñado un montón de cosas porque he aprendido a estar leyendo código de terceros, no siempre mi código, no leo código que no sea el mío, leo código de gente y me ha ayudado un montón de cosas con Symfony, por ejemplo. Yo defiendo mucho Symfony en ese sentido porque hay un montón de patrones bien implementados que yo aprendí un montón de cosas con el código de Symfony, por ejemplo. Y lo aprendí porque tenía que bucear a ver por qué Sinfonía hacía las cosas como las hacía, vale. Pero esto los juniors no lo están haciendo. Los juniors están usando ChatGPT para que les solucione un problema que ellos no están pensando. Entonces no van a saber resolver el problema. Entonces no es que, o sea, yo como senior no estoy muy preocupado, pero sí los juniors deberían preocuparse de intentar usar lo menos posible ChatGPT, y no solo en programación, en cualquier cosa. Yo creo que el problema es eso, que la gente se está acostumbrando a no pensar, y si no piensa no memoriza, ¿no? Y eso sí que, o sea, que eso ha sido un problema.

Otra cosa que había escuchado era que querían utilizar la interfaz de ChatGPT para directamente que le pidas exactamente lo que quieres hacer de forma explícita y él genera el código máquina directamente. De lo que tú le estás pidiendo, como si fuese el lenguaje de programación.

Pero tú y yo, que hemos trabajado ya mucho, sabemos lo que cuesta que alguien te dé las especificaciones de requisitos bien. Como para que eso ocurra en la vida real con un chat. Es decir, una persona que no es técnica, que es el que tiene el problema, siempre da las especificaciones mal. Y tú las tienes que refinar. Yo creo que eso, no digo que no pase nunca, Pero a corto plazo no va a pasar. Ten en cuenta que al final todo esto son modelos estadísticos. Por mucho que tenga la palabra inteligencia por ahí por medio, son modelos estadísticos que se basan en información previa. Y la información previa es escasa o está mal, la respuesta estadísticamente va a ser mala. O sea, el modelo no tiene forma de saber si realmente la respuesta es correcta. No, o sea, o la mejor posible de todas, te va a dar la más estadísticamente probable. Pues digo que yo creo que hay mucho humo al respecto porque interesa que haya humo, interesa que haya inversiones y haya rondas de inversión, interesa engordar la burbuja un poco en ese sentido, pero no es tan exagerado. Sí que es verdad que creo que esto es la siguiente revolución industrial en el sentido como lo fue con la máquina de vapor, etcétera, la producción en cadena, tipo de cosas. Es decir, que lo que va a pasar es que va a abaratar la programación. Antes de una aplicación pues costaría X, y ahora costar mucho menos. Entonces va a ganar menos porque la aplicación vende menos, pero entonces tienes que ir a un modelo de, en vez de ganar por margen, ganar por volumen. Porque es más barata, pues antes gente que no podía pagarla lo va a poder pagar, con lo cual, bueno, pues la que no tiene ganancia por margen pues ahora va a tener por volumen. Entonces lo que va a abaratar la informática y la gente, y gente que antes no tenía una aplicación, ahora la puede tener. Por ejemplo, una peluquería que para coger la cita lleva por teléfono y un chatbot te coge la cita, antes costaría miles de euros y ahora posiblemente se venda como un pack de una solución cerrada a X euros al mes. Y eso sí lo puede pagar una peluquería, a lo mejor. Pues por ahí va a ir el tiro, en el sentido, va a abaratar la cosa Pero como va a llegar a más servicios, más productos, va a haber nuevas ideas que antes no eran posibles o nuevos clientes que antes no estaban disponibles. Con lo cual, yo creo que el trabajo no va a faltar.

Pues bueno, yo creo que ya llevamos bastante rato hablando. Ha sido una buena charla. Hemos estado sobre programación así en general. Gracias, muchas gracias por haber aceptado la propuesta. Si quieres decir algo para despedirte.

Nada, muchas gracias a ti por pensar en mí. La verdad es que ya sabes que de la carrera nos conocemos, que soy una persona que me gusta hablar de programación, y en Córdoba por lo menos siempre que junto con gente intentamos organizar cosillas de este tipo también en Córdoba, de hacer comunidad.

Sí, bueno, de hecho he visto que la Salmoria Jotech ya está anunciada para el año que viene.

La Samorejo Tech está anunciada hoy y va, te creo que el 9 de mayo, que es viernes. Coincide con los patios quizás, porque no sé si al final van a los patios. Los queríamos ver abrir por el tema del calor, que las flores se secaban. Si no mueven los patios, sí coincide con los patios de Córdoba, 9 de mayo, viernes, en el rectorado. Este año volvemos, vuelven al rectorado, que lo organizan, yo no organizo, lo organizan los chavales del y chavalas del aula de software libre.

Pues lo dicho, un placer que haya estado con nosotros aquí en el programa. Y bueno, nos vemos la siguiente semana con otra charla en Codeadores.