Principios de Programación con Camilo Chacón

Pues buenas, estamos aquí otro día más, otra tarde, otra noche, bueno, otro momento en el que te pille escuchándonos en Codeadores. Hoy tenemos con nosotros a Camilo Chacón. No sé si decir tu tercer apellido porque es bastante, como se dice, parece como eminente, ¿no? Es un apellido tan poco escuchado que da la sensación de que podría conocérsete como Sartori. En lugar de Camilo Chacón. Me pasa mucho con mucha gente, como con Bécquer y otros literatos de nuestra historia. Pero bueno, estamos con Camilo Chacón Sartori y lo he invitado porque ha publicado, bueno, publicó hace un año un libro que es bastante interesante. Yo lo tengo en mi antibiblioteca de momento, no he terminado de leerlo, pero estoy en ello porque me parece un libro muy interesante y que hay que dedicarle su tiempo para ir sobre cada sección. Y me parecía interesante invitarlo para hablar sobre, sobre todo, las primeras partes del libro que esbozan lo que es todo el contenido que viene a continuación. Y antes de empezar a hablar sobre el tema, yo siempre pregunto, bueno, doy la posibilidad para que el invitado se presente y te hago la primera pregunta, además de cómo te introdujiste tú en el mundo de la informática, cuál fue ese primer momento que dijiste yo me quiero dedicar a esto.

Vale, como presentación, bueno, muchas gracias Manuel por la invitación. Mi nombre, como bien tú dices, Camilo Chacón Sartori, soy chileno radicado ya en Barcelona, España. Estoy en mi último año de doctorado en inteligencia artificial y bueno, trabajé anteriormente en la industria como ingeniero software, así que tengo esas dos patitas, una parte de la ingeniería y la otra parte más de de ciencia, y por otro lado también escribo libros. Así que soy un apasionado a la informática y también a las partes más de la humanidad que conlleva la escritura y la lectura. Ahora, yendo a la pregunta de cómo comencé a programar, bueno, yo creo que fue porque en realidad al principio me interesaban los ordenadores. Simplemente empecé de niño, antes de tener 10 años, en la escuela a usar los típicos software de ofimática, Word, ese tipo de dibujo, Paint, ese tipo de cosas en Windows. Y de ahí, de poco a poco, ya después cuando tuve a los 10 años mi primer ordenador, empecé a ocupar IRC, y ahí con IRC empecé a colocar mis primeros comandos, que eran cositas así muy simples, descargando, me acuerdo que en ese tiempo animé películas desde ahí. Y ya empezando después a tocar HTML, haciendo páginas web muy simples de Dragon Ball, recuerdo, Bola del Dragón, y cosas de ese estilo. Eso que claro, ya no, eso no es necesariamente programación, pero ya así podía haber algunos lenguajes etiquetados, como la idea de tener comandos para darle instrucción a la computadora. Ya lo empecé a ver desde los 10 años, y la programación como tal empezaría ya en los primeros años de la universidad, a los 18 años, cuando tuve C. Y después posteriormente Python. Yo aprendí primero C, después Python, aunque realmente creo que aprendí bien a programar cuando conocí Python, porque por ese tiempo, el 2008, por ahí más o menos. Y bueno, recuerdo una anécdota muy interesante, era que tuve un amigo que me enseñó, que me motivó a programar porque era muy buen programador, y cuando tenía como, no sé, 17 18, 19 años, y siempre me motivaba a programar. A él le encantaba mucho programar, era muy buen programador de C++, recuerdo. Y aparte programaba en videojuegos, lo cual tenía una destreza bastante, bastante buena, porque programar videojuegos es una programación bastante sofisticada. Y claro, a través de él me motivaba bastante continuar programando. Pero claro, después, curiosamente, a pesar de que él me motivó todo el tema, ya después dejamos de de tener una relación, porque me di cuenta que, claro, él se transformó en una persona más ambiciosa, en otro sentido de la palabra. Estaba más enfocado, más que lo que yo creía en su momento que era la pasión por la informática, era la pasión más por el dinero. Y después perdí un poco el contacto, pero bueno, no tiene nada de malo. Pero lo que voy es que uno muchas veces se motiva o te inspira personas que quizás personalmente no no tienen, no tienen muchas coincidencias a nivel personal, no tienen otra, o al principio tienes una imagen distinta de esa persona, pero aún así, aún así te motiva para continuar y después tú mismo crear tu carrera, aunque se separen, no, pero esa persona te ayudó quizás de manera indirecta en un comienzo, no. Así que así sería un poco mi inicio de programación, no, que tuve una persona que me ayudó bastante, me motivó a través de su ejemplo de lo que le gustaba la programación. Y empartí con C y con Python. Esos dos ámbitos los toqué al principio y creo que eso me ayudó bastante, conocer el bajo nivel y un poco lo que era el alto nivel, en el sentido de una escritura mucho más simple y fácil como lo era Python, como lo sigue siendo Python.

Yo creo que muchas de las personas que hemos aprendido programación Bueno, los que han sido de niños, obviamente hemos comenzado con un lenguaje muy básico, BASIC de hecho, en ordenadores personales muy pequeñitos. Pero las personas que normalmente me he encontrado que aprenden programación directamente en la universidad, su lengua madre, por decir, la primera lengua que aprendieron, el lenguaje C. Y yo creo que es un cambio muy brusco, porque quien aprende con BASIC, luego y lenguajes que son muy simples se lleva la idea de que es casi como un juego, es algo que es poner palabras, líneas, y va haciendo algo dentro de la pantalla. Y sin embargo, C da la sensación de que tienes que tener mucho más control de lo que hay detrás. No es simplemente escribir algo, sino que tienes que tener un poco más de idea. Tú encontraste, porque supongo que tu primer lenguaje sería C, ¿no? ¿Encontraste esa O sea, esa fricción inicial.

Sí, sí, el tema de la sintaxis era siempre un tema, era bastante gordo, que a veces no compilaba porque faltaba una llave o ese tipo de punto y coma, los típicos errores del comienzo. Y sobre todo porque hay conceptos que eran muy abstractos, por ejemplo, el concepto de puntero era algo muy que te volaba un poco la cabeza. Volar la cabeza, esa idea de poder tener manejo sobre direcciones de memoria o el concepto de referencia, el concepto de tipo, ese tipo de cosas se te lo va incorporando, estás obligado a saberlos. Entonces claro, es una carga cognitiva muy fuerte quizá al principio, y yo recuerdo que en realidad no aprendí tanto C en ese comienzo, lo aplicaba pero no estaba realmente comprendiendo bien lo que estaba haciendo, hasta que ya empecé a ocupar Python y ahí empecé a entender más la parte algorítmica, no, de resolver problemas a través de un lenguaje de programación. Y después, cuando volví a C, porque era como casi en paralelo los semestres, ya entendía mucho mejor C, no, o sea, cuál era su idea, cuál era el trasfondo de eso, y que por qué existían los punteros en C y en Python no, sino que las referencias se manejan de manera mucho más más simple, y por qué C tenía ventaja porque tenía sistema de tipo y Python no. Entonces ese tipo de cosas creo que son bastante útiles. Haber tenido la experiencia del comienzo de tener un lenguaje tipado y un lenguaje dinámico es interesante porque al menos de ahí vas como, ves una bifurcación, o sea, qué lenguajes son más útiles para una cosa y qué otros lenguajes son más útiles para otra cosa, ¿no? Estaba claro que Python iba a ser un lenguaje que iba a beneficiar a las personas en el sentido de que iba a ser mucho más legible, mucho más fácil de entender, de leer código Python que de leer un código C, que era mucho más, a los que les gustaba mucho más C eran personas que les gustaba mucho más. Y bueno, de hecho, entre paréntesis, yo creo que uno igual elige informática porque tampoco le gustan mucho las personas. En general, cuando uno es más, si no, si te gustan las personas, no tiene nada que hacer aquí. Hay muchas carreras donde puedes tratar con seres humanos. Pero realmente, cuando tú eres más introvertido, hay un cierto amor a la abstracción, o sea, en enfocarte, aislarte en tu mundo en base a conceptos, números, códigos, y uno en sí encuentra un placer en eso. Y claro, y había gente que encontraba ese placer aún mucho más en cuestiones mucho más de bajo nivel, como C.

Y si ahora mismo tuvieses que utilizar algún lenguaje, porque supongo que ahora para tus trabajos y tus tareas tendrás que seguir programando aún estando en investigación. Sinceramente no sé exactamente si va primero la documentación y toma de datos o si ya directamente te pones a programar, pero ¿qué lenguaje de programación normalmente utilizas para estos casos?

Sí, ahora bueno, generalmente estoy probando más en Python y a veces en C++. C++ solo algoritmos de optimización. Mi área son, mi área trata de algoritmos de optimización, que eso es un área matemática. Y dentro de esa área matemática, nosotros lo que, al menos en mi tesis doctoral, trata es incorporar los LLM dentro de esa área, o sea, cómo mejorar ese algoritmo ocupando ese tipo de tecnología. Entonces, claro, cuando tú ocupas LLM estás obligado prácticamente ocupar Python. Python, tú te conectas a las APIs, crear los prompts, todo ese tipo de cosas, que la labor de construir herramientas con LLM es muy de ingeniería software. Entonces para mí es facilísimo, o sea, para mis compañeros eso es súper difícil. Para mi director de tesis es sumamente complicado, no, o sea, el tener que conectarse a una API, a crear una aplicación web, conectarse a una base de datos, una API key, todo ese tipo de cosas, conceptos para ellos son, no los conocen porque generalmente son matemáticos, no. Entonces simplemente programan en C++ y ya, no. Pero para mí ese tipo de cosas muy fácil, entonces a mí los LLM se me hace más natural, es muy, muy ingeniería software. Y claro, con hacer ese trabajo es mi día a día, es Python. Entonces ahí con Ollama, esos frameworks típicos para LLM, y de ahí después con el código C++, que lo escribo menos porque muchos códigos ya están, ya están, lo tengo, los tengo programados, pero simplemente estoy creando alguna estrategia ahí con los LLM para mejorar los resultados con a estos algoritmos. Y también a veces creo una página web según mis temas, de por ejemplo herramientas visuales con JavaScript. Ahí ocupo también TypeScript. Pero sí, esos son los lenguajes que ocupo más: C++, Python y TypeScript. Podríamos decir que son como los que ocupo más frecuentemente. Igual es inusual porque en mi área yo estoy creando una combinación ahí híbrida entre temas distintos, pero en otros compañeros distancias, conocemos más los 4 años y nada más.

E iniciativas como Julia o Mojo, ¿no han permeado en esta sección, en esta área?

Julia sí, en su momento. Bueno, yo también fui bastante entusiasta con Julia. En algún momento escribí hace ya varios años atrás alguna publicación en un blog, en un podcast también que hablé sobre Julia. Creo que cuando fue mi primer año de doctorado, hace 4 años atrás, cuando hablaba mucho, estaba muy entusiasmado con Julia. Pero resulta que, claro, en algún momento choqué con la necesidad de tener algunas bibliotecas que ya estaban en Python súper establecidas, sobre todo cuestiones más científicas, y en Julia no estaban en ese momento. El ecosistema estaba ampliándose, pero no era tan fuerte como comparado con Python. Entonces al final dije, bueno, al final la ventaja tampoco es tan sustancial para lo que estoy haciendo, para la tarea que estoy haciendo. Así que simplemente me fui a Python. Y hoy en día en realidad tampoco veo una gran ventaja en Julia. Perdí un poco entusiasmo con Julia, no aprendió tanto como hubiera esperado. Se transformó más como algo de nicho, o quizá más empresarial, no sé, pero no fue lo que pensaba en su momento que iba a hacer. Es que lamentablemente competir contra Python es difícil, en el sentido que ya tiene todo un ecosistema enorme y que además ya hay tantas cosas para hacerlo más eficiente, y hay bibliotecas bastante buenas. Al final ocupan Python simplemente como una interfaz porque en realidad están ejecutándose en C++ por detrás. Así que no sé, hasta llegó un punto que ya no siento necesidad de ocupar Julia, pero sí sé que Julia lo están ocupando bastante en optimización, pero obviamente el rey en esa área es C++. Y con respecto a Mojo, también tengo ahí un estado entusiasta, hice un taller hace un año atrás sobre Mojo, y de hecho tengo ahí un vídeo con nuestro Patricio en Dojo sobre introducción a Mojo, y está muy bien, está muy bien, pero no me perdí un poquito en realmente lo que está ahora, en si han avanzado mucho más. Pero claro, o sea, la idea original de Mojo de de hacer una especie de superset sobre Python. Es interesante, interesante. Pero sí recuerdo cuando yo ocupé la versión 0 punto y algo, claro, habían cuestiones que eran una sintaxis nueva que se le incorporaba a Python que no era para nada trivial, no. O sea, tampoco, también lo hacía bastante más difícil también de escribir. En ese tiempo ni siquiera estaban los diccionarios disponibles en Mojo implementados. Ahora ya debe estar, me imagino, pero veremos qué pasa. Pero bueno, eso sería una especie casi de santo grial, tratar de tener un lenguaje que tú directamente todo tu código Python lo ejecutara directamente en un compilador de Mojo y fuera más rápido. Pero no sé si eso sea técnicamente tan fácil de lograr.

Y bueno, la última pregunta antes de entrar directamente en los principios de programación, principalmente por curiosidad: ¿qué lleva a una persona que entra en el mundo laboral dentro de la empresa, que está realizando códigos y programas y está dentro de equipos de desarrollo, a decir de repente, bueno, no sé si sería de repente o si fue una decisión muy meditada, el hecho de saltar a una rama completamente diferente como es la investigación y la escritura de libros.

Bueno, escribir, a mí sí me gustó escribir. Recuerdo que antes escribía un blog y escribí Escribí mucho en Quora también antes de empezar a conversar, a escribir libros. Y en Quora fue como un taller de aprendizaje de escritura donde me di cuenta que lo que escribía a la gente le importaba. Eso es muy importante para escribir, esa confianza de decir, vale, hay gente que le gusta lo que escribo. Y eso es fundamental, no tener esa retroalimentación, y porque al final te dice al menos que puedes escribir claro. Ya con eso ya es Si tú escribes claro, ya es bastante bueno, es un punto de partida. Y en Quora, claro, me dieron después escritor destacado y ese tipo de cosas. Entonces ese tipo de cosas te dan confianza, y por varios años seguidos. Y después lo que era la investigación, claro, a mí el tema está que siempre trabajé en la industria, pero también estudiaba en paralelo, y me fue siempre bien la universidad en general. En carrera de grado, en el máster, siempre como los primeros lugares. Me iba bien, aunque en general la carrera de grado, las carreras como de gestión, me iba mal. O sea, todo lo que era administración de empresa y cosas así, esas cosas no me gustaban nada. Pero lo que era programación, la parte técnica, siempre me fue bastante bien. Y claro, después la tesis, que eran mis temas que yo podía elaborar, los temas que yo quería, claro, eso me hacía subir mucho el promedio final, ¿no? Porque al final te dan como un porcentaje, ¿no? O sea, el 60% todo el promedio de tu asignatura, el 40% era la tesis. Entonces, si la tesis tú tenías un 7, que en Chile 7 es la nota máxima, te subía muchísimo todo lo demás. Entonces siempre sacaba como los primeros lugares. Y en el máster también. Entonces, en el máster cada vez era mejor porque ya yo podía tomar asignaturas que me gustaban, no era como la de grado que estaba obligado a pasar asignaturas que no me interesaban. Y al doctorado es como la cúspide de eso, ¿no? Ya empezar a atacar temas que realmente te gustan, simplemente. Ya no tienes, no tienes asignatura. Y claro, lo que yo tengo bueno, al menos, que me puedo autogestionar. A mí me encanta autogestionarme, no tener jefe, y sé que voy a cumplir con mis plazos. Por ejemplo, mi director, es decir, nunca yo le he contado, rara vez, que he publicado libros, porque es como otra faceta mía. Yo no me meto mucho, no mezclo mucho el doctorado con los temas de los libros. Porque si no me diría, pero no tienes que escribir porque tienes que dedicarte al doctorado, todo ese tipo de cosas. Pero bueno, ya se rindió. Ya a esta altura ya cumplí con todas mis publicaciones, así que ya estoy bien. Pero sí, o sea, a mí me gustó siempre la parte de la academia porque no tengo jefe, tan simple como eso. No me gusta tener como tener tareas constantemente, soy más perezoso en ese sentido. Me gusta hacer las cosas a mi manera. Y bueno, yo creo que la academia es un buen lugar para ese tipo de personas, aunque ganen menos dinero. Y pero la industria también me enseñó mucho, o sea, la industria, haber trabajado en Telefónica, en IMATEC, ahí aprendí a programar bien. Yo creo que esa fue una de las grandes experiencias que tuve. También anteriormente, mi primera empresa en Chile de software fue una que se llama Mining Tech, que es de minería. La industria minera es muy importante en Chile, y ahí emprendí una cosa que nunca se me ha olvidado, la importancia del hardware para el software, ¿no? O sea, cuán importante es dónde se va a ejecutar tu código. Y claro, en las condiciones que se ejecutaba el software ahí, con las condiciones mineras, la falta de señal, que tú tienes que crear algoritmos, sistemas que tuvieran pendiente a ese tipo de cosas, te cambia la perspectiva de lo que es el software, ¿no? No es lo mismo crear un software de facturación, algo así, que un software que tienes que tener en cuenta que la señal de WiFi va a ser mala y el computador se puede apagar en cualquier momento. O que se puede calentar o que no hay espacio en disco duro, etcétera, porque ahí está en condiciones extremas. Y después en Telefónica ya aprendí la importancia de la documentación, de escribir bien, que un código sea rápido o que funcione no es suficiente, sino que tienes que escribir código para humanos, porque había muy buenos programadores ahí, gente que era y que tenía muy buenas habilidades blandas, como se dice ahora. Por tanto, fueron esas dos combinaciones. Y además que siempre me interesó la academia, por lo que te dije anteriormente, que no me gusta tener mucho el tema de jefe. Y lo de Telefónica, bueno, además igual era como teletrabajo, no tenía mucho jefe en realidad, es como más libre. Me metí a la academia simplemente porque quiero seguir haciendo lo que yo quiera, los temas que me gustan, simplemente por eso. Pero si no, estaría en la industria igual, estaría feliz seguramente.

Bueno, pues empezamos ahora con las preguntas específicas que tengo del libro. Me despertó bastante curiosidad alguna de las páginas que leí. Y bueno, empiezo. Tengo aquí una copia del libro con algunos apuntes y demás. Y en la página 146 tiene un diagrama bastante llamativo que al principio, cuando lo vi, me llamó mucho la atención porque parte de lo que sería como un octaedro, vamos, con el centro en programación hacia cada una de las partes. Y vas poniendo, vamos, leyendo en sentido de las agujas del reloj, sería diseño, recursos, transformación, evaluación, ethos o ethos, documentación, coordinación estado, y en el centro programación. Igualmente pone dos áreas en el que la parte superior, incluyendo los lados que permanecen en los extremos derecha e izquierda, serían los principios técnicos, y abajo los principios de conducta. ¿Cómo llega a especificar esta cantidad de principios técnicos o detectarlos Es decir, ¿esto es algo que traías ya de tus tiempos de universidad y fuiste viendo en tu trayectoria, como has dicho, en Telefónica profesionalmente? ¿O es algo que ya ibas trabajando de forma lateral mientras escribías libros y fuiste esbozando lo que sería cada uno de estos principios? ¿Cómo van surgiendo estos principios?

Sí, es una buena pregunta. Claro, yo tengo 35 ahora. Ese libro se publicó el año pasado y tardé 2 años en escribirlo. Yo en algún momento mencioné que ese era mi libro de los 20, es decir, de mi libro de esa década, o sea, de la década de formación, el término universidad y las 2 experiencias laborales que te comenté, y que es la parte de ingeniería, no, de empresa, y además la parte académica. Entonces eso igual me dio una perspectiva quizá más general de haber ocupado múltiples lenguajes de distinto dominio. Algunos de bajo nivel cercano al hardware, otros de alto nivel como en Telefónica, grandes infraestructuras de datos, big data. Por ahí también había data science. En la academia entendí el tema de la optimización, la parte matemática, la precisión. Entonces quizá todos esos ámbitos me fueron dando un poco la idea de que todos los lenguajes de programación, todas las herramientas, hay ciertos principios que subyacen a todas ellas. Y una de las preguntas que uno ya se viene rondando, y mucha gente lo va divulgando últimamente, que es la idea de que los conceptos son más importantes que la herramienta. Eso era algo que ya se viene haciendo ahora y se repite constantemente, pero lo que yo preguntaba era cuáles son esos conceptos, porque la gente dice bueno, los conceptos son más importantes que las herramientas, los fundamentos Pero nadie te dice cuáles son los fundamentos y nadie te dice cuáles son los conceptos. Y hay algunos conceptos que son más importantes que otros y todo ese tipo de cosas. Lo que yo traté de hacer es, bueno, cuáles son los conceptos de los conceptos. Y a eso yo le llamo un principio, que un principio es que engloba múltiples conceptos generales. O sea, no hay un común. Si yo tomara esos 8 principios que están en mi libro, ¿cuál podría ser uno que englobara todo eso? Sería quizás la abstracción, cosas así que están presentes en todas partes. Pero si lo pudieran clasificar en 8, bueno, fueron 8 porque fueron los que yo encontré, pero pueden haber sido 9 o 10, ¿no? Y lo que sigue, detecté que eran de 2 categorías. Uno eran los principios técnicos, que eran simplemente habilidades que tú frente al computador empiezas a probar y aprender a través de la experiencia de creando sistemas, resolviendo problemas, aprendiendo distintos tipos de lenguajes. Y lo otro eran principios de conducta que tenían netamente que ver cómo te relacionas con las personas para cumplir una tarea de software, o sea, cómo llegar al objetivo. Y eso para mí era muy importante también, ¿no? Y ahí nace el principio de la documentación, porque la documentación es algo que tú demuestras que te importa a otra persona, no tan solo tu sistema, sino que otra persona para el futuro. La evaluación también, que es un principio de que tú evalúas algo porque también te importa, ¿no? Requiere cierta comunicación con otras personas. La ética, para qué hablar, ¿no? Que es el ethos. Y claro, ese tipo de cosas para mí era muy importante, principalmente porque quizás eso me di cuenta también en Telefónica, que es una empresa muy grande, está lleno de equipos pequeños, la importancia de saber comunicarte tus ideas. El software para mí es un problema humano, y como problema humano, el saber comunicarte te ahorra muchos problemas técnicos. Final, yo creo, los grandes problemas que ha tenido la empresa han sido más humanos que técnicos. Si tú te sabes comunicar bien con personas, los problemas técnicos se pueden solucionar, yo creo, en algún momento. Pero si no, es más complicado. Pero, y esas categorías fueron también, yo creo que las incorporé cuando leí el libro de Peter Denning, The Grace of Principles, con Peter Seiler, como los grandes principios. De la ciencia de la computación. Ahí también me dio como una visión general, era como la piedra que me faltaba para decir, vale, ok, esto lo podría llevar a otro ámbito, un ámbito más acotado como es la programación, ciertos principios, y añadir el tema de los principios técnicos, principios de conducta. Entonces, en base a esos 8 principios, como que puedo ir añadiendo distintas áreas de la programación, del desarrollo software, y herramientas también asociado a cada uno de ellos. Por dar un ejemplo, por ejemplo, el principio de coordinación tiene que ver con todo lo que es el mundo de la concurrencia, el paralelismo, la sincronía y todas las herramientas que rodean ese mundo, multicore, todo tipo de cosas. Y hay ciertas herramientas que son más acordes a ese tipo de concepto. Hace un rato, cuando estaba en otro streaming, alguien me preguntaba, decía que este libro de principios de programación es más como para alguien que se está iniciando. Y yo dije, bueno, en realidad no es tan así, porque en realidad es un libro más de intermedio avanzado. ¿Por qué? Porque si tú le hablas a alguien de principios y estar siempre estando a programar es algo muy abstracto. Realmente esto tú lo logras entender cuando ya tienes mucha experiencia ocupando muchos lenguajes, muchos tipos de problemas distintos en distintos dominios. Realmente ahí tú vas entendiendo, decía, la coordinación siempre aparece cuando trato de hacer este tipo de sistema. O la importancia de los recursos, el recurso de memoria, el espacio de disco duro, el diseño. Siempre aparece el diseño en todas partes, las transformaciones de un formato a otro. Bueno, ese tipo de cosas, si no tienes experiencia laboral, es muy difícil entenderla. Y también surge el tema de los principios para hacer un ataque contra los paradigmas, y que al final es un poco también uno de los motivos que surge, el paradigma de programación, que era uno de los conceptos que Sí es verdad que fue útil en su momento, porque entender la programación en base a paradigmas funcionales, estructurados, orientados a objetos, puede ser útil para comenzar a aprender programación. Hoy en día los lenguajes nuevos todos incorporan en cierta medida algún paradigma, en menor o mayor medida, pues son todos multiparadigmas por definición prácticamente. Entonces ya la idea de separarlo de manera rigurosa, fija, no tiene ya mucho sentido, al menos para mí. Entonces, en ese sentido, para ir, en vez de aprender la programación en base a ciertos paradigmas, mejor irla aprendiendo en base a principios. Yo podría tener incluso, no sé, un curso del principio de coordinación. Entonces, en coordinación seguramente veríamos concurrencia o algún lenguaje como Erlang o cosas así, no, que tengan que ver mucho con ese tipo de problemas. Y bueno, y en estado, que sería seguramente el lenguaje más de bajo nivel porque todo se mueve a través de un estado, tú lo ves claramente cómo ese estado se va moviendo. Sobre todo uno lo ve en lenguaje como assembly, ese tipo de cosas de muy, muy bajo nivel, y cosas así, ¿no? A mí al menos me da la sensación que si yo creaba esos 8 principios me daba una visión mucho más global de la programación y podía cubrir mayor espacio, ¿no? Y bueno, eso es lo que traté de hacer en ese libro, que bueno, al final uno cuando escribe un libro tiene una idea, una hipótesis de lo que te puede, de lo que puede ocurrir. Pero en realidad uno nunca sabe realmente el resultado. Al final yo me divertí haciéndolo. Creo que es un libro que es difícil a veces de entender realmente cuál es como el fondo, porque tiene muchas cosas, podrían ser como 3 libros separados. Pero bueno, al final, como cuando tú escribes un libro, tú lo sabes también, Manuel, uno nunca sabe cuál va a ser el resultado, pero uno lo importante es hacerlo al final, y después al siguiente libro. Al final tampoco hay que darle mucha vuelta.

La verdad es que los 8 principios que mencionas aquí me encantaron porque después de leer un poco de historia recuerdo Gene Samed, que escribió sobre las generaciones de los lenguajes, y recuerdo que cuando estaba en la universidad o incluso antes, los libros que tomaba siempre decían este lenguaje es de tercera generación, de cuarta generación, y realmente ya Gene Samed cuando publicó el libro de historia, que creo que fue en los 70 u 80, ya lo daba como una forma caduca de etiquetar a los lenguajes. Y ahora que has mencionado lo de los paradigmas, me resuena en la cabeza también como lo mismo, una forma caduca de intentar catalogar o categorizar los lenguajes de programación. Y bueno, esta realmente no es una forma de catalogación de los lenguajes per se, pero sí esboza bien lo que es las áreas que debes de cubrir Para decir al menos, como tú decías, de si llegas a un nivel intermedio avanzado, de tengo un buen dominio de la programación, voy viendo cada una del área y veo pues si tengo buen conocimiento en cada una de ellas. Uno de los que me llamó más la atención fue el de ethos, que vamos, creo que se puede traducir como ética, creo que estaba por aquí también especificado. Y me llama la atención porque siempre la ética la he relacionado con esa imagen que tengo de cuando se, cuando explotaron las bombas sobre Fukushima y Nagasaki, que la comunidad científica comenzó a hablar de la ética de los científicos, de no hacer nada por el hecho de hacerlo, sino también revisar la ética. Y que es un debate que ahora está volviendo otra vez con la inteligencia artificial, de mirar la ética de lo que se hace. Y lo veo aquí reflejado como un principio de programación. ¿Qué dirías tú que incluye dentro de esa ética que tenemos que conocer?

Sí, bueno, sí, el tema, por ejemplo, con la inteligencia artificial, siempre cuando te pregunta cuáles son los peligros que tú ves con la inteligencia artificial, al final yo creo que el peligro más grande no es tanto la inteligencia artificial como tal, sino que son las personas. Al final, el ser humano es el que va a tomar las decisiones, y ese es el peligroso en realidad. Y yo creo que el que va a regular, el que va a decir qué es una ética, porque en realidad, ¿quién define cuál va a ser la ética para estos sistemas? Va a ser un grupo de personas. ¿Y quién define a ese grupo de personas? Entonces es un problema casi al infinito. Pero bueno, la ética, lo que yo quería traspasar en ese capítulo era que hay una responsabilidad, una cierta, podríamos incluso, honestidad intelectual de tratar de hacer cosas que de un conocimiento, el conocimiento técnico que tú tengas sobre programación, lo ocupes para hacer mejor al mundo, podríamos decir, aunque suene un poco ingenuo, pero sí ocuparlo para cosas que hagan bien a la sociedad, no ocuparlo para hacer daño a la gente, o sea, tratar de hacer cosas de manera honesta. Eso yo creo que era un poco el tema de entender que uno cuando hace software, incluso hoy más que antes, repercute directamente a las personas y que puede perjudicar mucho a las personas. Yo creo que cuando tú creas, por ejemplo, bueno, hay cuestiones, hay cuestiones casi ya delictivas, ¿no? Que crean software para engañar a la gente. Pero en cuestiones más sutiles, como es crear herramientas que tú creas con la interfaz que para que sea adictiva esa herramienta, ¿no? Y que más gente lo ocupe, también hay una cierta responsabilidad y preguntas que tú te tienes que hacer, ¿no? En el sentido de, ¿eso es adecuado? O sea, Al final no es un delito, pero sí estás ocupando tu conocimiento de investigación en este caso para volver adicta a ciertas personas, ¿no? O sea, que más veces ocupen tu herramienta. Por un lado tienes una ganancia, pero por otro lado también tienes una responsabilidad, ¿no? Eso se ve mucho con las redes sociales. Las redes sociales son como el experimento más notorio de eso, ¿no? Hay gente que se pasa los Reels constantemente y puede estar toda la vida ahí, ¿no? O sea, Ese tipo de cosas también hay una responsabilidad de decir, bueno, esto es correcto, es correcto ser parte de esto. Son preguntas que quizá un informático debería hacerse de vez en cuando. Un lado es la parte técnica, que tú puedes ser muy bueno en eso, pero no hay que olvidar que software es como actividad humana, repercute a las personas. Y yo creo que, bueno, en esto, en hoy en día con el tema de inteligencia artificial, hacer cosas que que puedan ayudar a la gente y que muestren sobre todo transparencia de lo que estás haciendo es necesario, necesario, porque hoy en día estamos a merced de cuestiones muy de optimizar la mayor cantidad posible que la persona esté en la aplicación. Quiero que compre, quiero que pague, quiero que pase mucho tiempo ahí. Y claro, eso también es una, uno abusa de de ciertos sesgos humanos y se aprovecha de eso. Entonces, aprovechar tu conocimiento técnico para eso es como, son cuestiones que al menos a mí me interesaría dejarlo ahí en la mesa y que la gente pueda reflexionar sobre eso, que uno piense, porque muchas veces uno está con una especie de, va como de manera automática, o sea, no se para a pensar mucho las acciones que hace. Está en una tarea en el trabajo, la hace, la cumples y ya. Pero a veces igual uno tiene que pensar esta tarea, cuál va a ser el resultado, quién lo va a ocupar, cuáles son las implicaciones del código que estoy escribiendo. Eso creo que es importante, al menos no tan solo como programador, sino como profesional que trabajas en cualquier área humana.

No sé si estará ligado directamente porque estaba hojeando ahora las notas y demás. No lo veo ligado directamente, pero dentro del libro, en el tomo 4, que es de Somos humanos, Sería el título perfecto para lo que estabas comentando. Y también el tomo 5, que menciona Buena Vida. ¿Cómo crees tú que esto—? O sea, porque el de Somos Humanos está claro que es, después de leerlo, es casi como una llamada a la atención a coordinarnos, a hablar entre nosotros, compartir y ser humanos. Pero el quinto, Porque he visto mucha gente que considera la profesión de la programación muy estresante, tienen motivos para ello, y claro, ves un tomo completo que se dedica con el título Buena Vida. ¿Qué quieres transmitir exactamente con el contenido de ese tomo?

Yo creo que ahí lo que trataba de transmitir era cómo poder coinciliar, o sea, la parte técnica, que puede ser una cuestión muy excesiva, que te abstrae mucho de la realidad, la realidad del día a día, tu familia, tus amigos, de salir a tomarte un café o salir a pasear, con la parte más humana, la parte más de los, podríamos decir, de sentimientos, de distraerte, de tratar de encontrar ese equilibrio que muchas veces para un área como esta es difícil de conseguir un equilibrio. Entonces lo que era buena vida era un poco eso, ese equilibrio, tratar de decir que creo en algunas partes también mencioné la importancia de salir a caminar, de la importancia de salir a pasear, cosas así que son cosas muy simples pero a veces ayudan muchísimo. Yo, por ejemplo, hace no mucho tiempo empecé a hacer ejercicio. Ahora estoy transformándome en una especie de gym rat o gym bro. Entonces claro, y parece gracioso, pero yo sí me reía un poco la gente que hay Pero me siento mucho mejor, de hecho muchísimo mejor en cuanto a energía. Tengo menos dolores de espalda, tenía dolores de espalda y tenía, y tengo 35 años, y pensé, dije, en 10 años más voy a estar muerto. Entonces cosas así, no, que son cambios menores pero que te ayudan muchísimo, o sea, y te ayudan incluso para lo que tú te interesas, que es seguir escribiendo, seguir programando. Ese pequeño tipo de cambio te ayuda muchísimo también. Por otro lado, el tema de cultivar las relaciones sociales, tener pareja, amigos, cosas así. Ese tipo de cosas era un poco lo que quería mencionar en eso, ¿no? La importancia del contacto humano. Al final somos seres sociales, por más que al principio haya dicho que como informáticos, como somos más introvertidos, como no nos gustan tanto las personas, nos metemos en este mundo. Sí es verdad, pero también es importante buscar ese equilibrio de vez en cuando, ¿no? De desconectarse, porque muchas veces desconectarse nos ayuda a resolver problemas y hacerlo mejor. Entonces, un poco ese tomo era explicar eso, que la informática está muy bien, está genial, pero también hay que hacer otras cosas que incluso te pueden ayudar para potenciar tu interés por la informática.

Volviendo hacia atrás, en la página 31 hay otra de las cosas que también me llamó mucho la atención de forma muy positiva, y es que hay pocos libros que haya leído que tengan su mapa de lectura, porque normalmente en la sección de introducción puedes encontrar a quién está dirigido este libro, y te explican un poco de, bueno, si eres tal persona, pues te dan algunas recomendaciones, pero queda un poco en el aire, no te aterriza nada de cómo tienes que utilizar el libro de cierta forma. Pero sin embargo, tú lo has puesto con un esquema que se ve claro y detallado. Leo literalmente: si buscas aprender conceptos más generales de programación, y entonces le das una ruta de capítulos para que vaya leyendo y se vaya Siguiendo esa ruta. Y después tiene otro de busca aprender más sobre la historia de la programación, y entonces le da otra ruta diferente que viene a nutrir más ese interés diferente al primero. Y bueno, ya después también el buscar las raíces de la programación, o lo que decía al principio, de buscar aprender a ser mejor profesional, que yo creo que al final lo que la mayoría de gente, por lo menos yo, buscaba con este libro de intentar rellenar los huecos que no tenía o ver qué me faltaba para tener la conciencia de, vale, ya sé los principios de programación. O sea, al hacer este mapa de lectura, ¿tenías claro ya que ibas a escribir diferentes capítulos para diferentes lectores?

Tenía claro más o menos cómo iban a ser los tomos, que los tomos engloban varios capítulos, pero sí, la idea era tener un libro que tratara distintos tipos de interés, ¿no? El primer tomo más técnico de introducción a conceptos, el tema de la historia también aparece por ahí, el tema de consejos, ¿no? Que al final hay una parte también de un pequeño diálogo ficticio, ¿no? Que también lo quería incluir. Entonces la forma de incluir tantos tipos de cosas fue agruparlo en esos tomos, ¿no? Y esos tomos yo sabía al principio que iba algunos lectores a más uno que otro. Entonces dije, bueno, ¿por qué no hago un cierto mapa de lectura? Porque yo pensé los tomos, esto es muy importante, no como una lectura lineal. Cada tomo es independiente. Yo podría partir por el tomo 5, después por el 2 o por el 3, y después por el 1. No hay problema en ese sentido, pues están divididos como en tomos. Y en base a ser tomos independientes es necesario tener quizás una ruta. Yo puse ahí una ruta tentativa, pero la gente podría elegir la ruta que ellos quisieran según leyendo el índice de los temas de cada uno de los tomos. Y como, y bueno, también era un poco porque la idea del libro, creo que lo menciono en el prefacio, en la introducción, que yo tenía pensado escribir un libro de libros, un libro que más que ser un libro cerrado que te dijera estos son las cartas, o sea, rígida totalmente de la programación, sino que sea un libro que te expandiera, que te recomendara muchos libros. Está lleno de recomendaciones de libros. Yo me preocupé mucho de colocar todos los libros que he leído, mis favoritos, colocarlo en recomendación en algunas partes, y que sea una especie de biblioteca donde tú puedas acceder y que te lleve a otras lecturas. Al final, eso es algo que a mí siempre me ha gustado, no los libros que te dicen que las cosas van a tener que ser así y así tal, así, y ahí termina. Sino que son libros que te llevan a otros libros, que te recomiendan a otros autores, otro tipo de lectura. Y claro, eso es un poco lo que yo quería transmitir en este libro, dejar que no sea cerrado, sino que sea abierto para que más gente siguiera explorando el mundo de la programación.

Bueno, de hecho, el primer tomo que llamaste Fundamentos, veo que el primer capítulo lo dedicaste a los fundamentos matemáticos, la lógica y toda la matemática que siempre está ligada con la programación. Y después yo diría que los capítulos 2, 3 y 4, que son los conceptos elementales, los algoritmos y estructuras de datos y el pensamiento computacional, serían la base para aprender lo que es la programación en sí. Tener en cuenta que hay muchos detalles y diferentes, que muchos de ellos incluso están presentes en la mayoría de lenguajes de programación, pero con matices. Algunos lo tienen exactamente tal y como lo mencionas y otros lo tienen pero de otra forma que depende más de la destreza del programador a utilizarlo. ¿Qué lenguaje dirías que casa mejor con todo lo que has especificado en estos 3 capítulos?

Sí, es una buena pregunta. La lógica para mí era importante en cuanto a lógica matemática para intentar como aprender a razonar. Era un poco esa la idea, que cuando tú tienes como a razonar una frase en lenguaje natural, o sea, tratar de razonar en base a esa frase y decir, bueno, las implicaciones que esto tiene, es un AND, un OR, que son las operaciones básicas de lógica. Para mí eso era muy importante al comienzo. Yo creo que un lenguaje para que englobe eso, dando un lenguaje muy, muy bueno, nada, para nada extraño, Python es como lenguaje que muy simple sentido que tú ya te abstraes directamente de la sintaxis compleja y te va directamente a la parte algorítmica. Creo que eso puede ser una buena idea, o sea, entender el tema de las puertas lógicas, la importancia de los if, los else, ese tipo de de cosas, para mí yo creo que puede ser Python una buena alternativa, o cualquier lenguaje que la sintaxis no sea muy compleja. O sea, no podría decir Rust, no, por ejemplo, Rust ya requiere mucho más destreza en este tipo de cosas, pero lenguaje que sea muy parecido al pseudocódigo. De hecho, hay un capítulo, creo que no sé si el segundo, donde muestro como pseudocódigo de un lenguaje, y es un lenguaje, claro, que podría ser muy similar a lo que es BASIC o lo que es Python, cosas así.

Incluso dentro del capítulo 4 puedo ver que trata en una sección sobre la encapsulación, pero no recuerdo exactamente la orientación a objetos. ¿La tienes presente y se menciona o se explica en sus detalles y demás? Porque es que es un tema enorme siempre.

Sí, sí, sí, lo menciono sobre todo en la parte que no recuerdo exactamente, uno de los principios también donde menciono el tema de la orientación a objetos, sobre todo lo que es la modularización, como la importancia de modular tu software, de encapsular software. Y esto también viene a cuento, voy a contar una anécdota que me pasó hace poco. No puedo contar muchos detalles porque son cuestiones más como basadas en un un contrato, pero vi un código que tenía que revisar en Python. Y claro, él nunca había visto un código tan mal escrito en mi vida. No había ninguna, o sea, hizo, hizo lo que es difícil de lograr, no, hacer ver código Python horrible. Eso es muy difícil de lograr, de hecho, porque Python ya te restringe muchas cosas. Pero una de las cosas que me di cuenta ahí Y ahora lo conecto un poco a la charla que hiciste con estos, Patricio, donde hablaron mucho del Tío Bob, no, el código limpio. Yo también comparto con usted la opinión sobre el código limpio, o sea, el tema de tener consejos rígidos, todo este tipo de cosas. Pero yo dije, vale, una persona que escribe este tipo de código, que era el que yo vi, que primero no declara bien las variables, tiene funciones enormes, o sea, no refactoriza absolutamente nada, todo, toda la lógica está en una sola función de 500, 600 líneas. Mucho código duplicado, sin comentarios. Entonces, claro, si tú le das un libro del código limpio, seguramente le va a ayudar a una persona así, ¿no? O sea, depende del nivel de gravedad. Hay personas que le pueden sacar más provecho que otros, ¿no? O sea, cuando tú ya tienes cierta experiencia, que el Clean Code no te va a ayudar mucho porque te va a restringir demasiado, ¿no? Te va a decir, bueno, estas son como las pautas y tienes que seguirlas a rajatabla, ¿no? Pero cuando una persona no tiene, no es informático de entrada y ha escrito código, está ahí luchando sin ruta, ve un libro como ese, un libro como ese le va a ayudar yo creo muchísimo, muchísimo, para al menos tener, decir oye, crea funciones más pequeñas, no preocuparte los nombres de variables, cosas muy simples como esa, no. Claro, entonces yo pensé, dije claro, el Clean Code quizás no es tan, no es tan malo después de todo, quizás para cierto tipo de personas que tiene un desastre en la cabeza puede ayudarle, no. Pero ya cuando tiene más experiencia te das cuenta que ese tipo de libros no no te restringe demasiado. Pero sí, era un poco esa la anécdota que quería contar. Al final son cuestiones, claro, que uno a veces queda un poco choqueado.

También veo que dedicas parte a la programación concurrente, que yo creo que es una gran olvidada muchas veces en la programación. Y sin embargo, después de Fred Hebert, que dijese lo de se acabó el almuerzo gratuito, la famosa charla en la que dio como paso que se implementasen más núcleos dentro de una CPU en lugar de tener más gigahercios. En ese punto, yo creo que la programación concurrente debería de ser casi obligatoria para tenerla presente y siempre, o sea, no utilizarla de forma O sea, sin sentido, no, siempre que tenga su sentido. Pero, y vamos, creo que la parte de coordinación que menciona en el libro es bastante esclarecedora en ese sentido, porque da las bases. Y tal y como dices, pues después tiene sus recomendaciones. ¿Qué es la parte más difícil que resaltarías de coordinación?

Pues yo creo que entender que la computación se puede distribuir y que puede ocurrir un caos en esa comunicación. Creo que quizás lo más importante que una persona entienda, o sea, que primero que tú puedes dividir la computación en computadores que están en una red y que siempre están proclives al caos, en el sentido de que va a haber errores que son inevitables prácticamente, porque un computador se puede apagar en mitad del proceso. Entender eso, de hecho, ahora que lo recuerdo en un bootcamp ahí de código facilito que me tocó hacer el temario. Nosotros tenemos un bootcamp de algoritmos, entonces tenemos múltiples clases con distintos tipos de algoritmos. Y ahora esta semana vienen las clases, o cuando aparezca este episodio, la clase de la semana pasada, parte de una clase de que yo no la doy, pero daba una persona que yo invité ahí de algoritmos distribuidos. Y lo que quería explicarle un poco al alumno, y un poco lo que explicar ahora, y lo que quería explicar en ese en ese capítulo es que primero una cosa es crear un algoritmo como ordenamiento, los tipos que te enseñan en la universidad, que tú lo ejecutas en un computador aislado y ya. Y otro mundo es el cuando tú sales de ese computador y lo ejecutas en una red, ¿no? Y ahí aparecen todo tipo de, para, bueno, de proceso, estrategia, ¿no? Como MapReduce, tipo de cosas que es un poco la computación moderna. La computación en la nube se basa en algoritmo distribuido, ¿no? Entonces, para que la gente un poco entienda que, ah, ok, mi algoritmo, puede haber algoritmos que están ejecutándose en una red, no, que están operando y están colaborando, no. Y toda esa colaboración, esos errores que pueden ocurrir, se basan en una coordinación, no. Es extremadamente importante tener una coordinación, porque si no hay una coordinación no va a funcionar, no. O sea, no va a ser lo que decía Lamport, no, que al final un sistema distribuido es que tú no te das cuenta que es distribuido prácticamente, no. O sea, Es como que tú lo notas transparente para ti, aunque hayan errores entre medio de algunos nodos, sigue operando, para ti es transparente. Y todo eso no es magia, sino que son algoritmos que están funcionando detrás. Y todo eso que logra hacer que eso funcione, el internet, por ejemplo, navegar por un navegador, por redes sociales, jugar un videojuego en multiplayer, etcétera, se basa a que hay un proceso detrás que es una coordinación que obliga a que ciertas cosas pasen antes que otras. Eso es como la idea fundamental. Yo creo que eso es como lo más importante de entender, y eso te abre como mucho más la cabeza, entender que cuando tú conectas un computador a un cable o lo conectas a WiFi, hay comunicaciones, hay datos que se están transmitiendo, y eso requiere una coordinación. Eso para mí era lo que quería expresar en ese en ese principio.

Otro tomo que me parece muy importante es el de sistemas, porque siempre lo he visto como la parte olvidada de la gente que aprende a programar, que se basan siempre en lo que se llama despectivamente como picar código, y siempre se olvida el conocimiento de dónde estás haciendo el código, como bien decía al principio con el ejemplo de la minería. Saber cuáles son las restricciones del sitio donde tienes que desplegar, los protocolos de comunicación que tienes que utilizar. Si estás programando para un móvil, saber las restricciones que tiene ese móvil. En este tomo incluso lo veo súper actualizado porque recuerdo mi libro de bases de datos que en aquellos tiempos cuando lo estaba estudiando ya estaba NoSQL, pero sin embargo en el libro no lo representaba. Y tú incluso incluyes la base de datos de vectores. Es bastante, bastante completo. Y sitúas también dentro de los sistemas los lenguajes de programación. ¿En qué punto puedes considerar como parte del ecosistema un lenguaje de programación?

Sí, una de las cosas del sistema como tal, yo lo concibo que es una herramienta, una pieza de código que tú diseñas pero que permite construir otra o que permite ejecutar otra sobre ella. Y claro, el sistema operativo es evidente porque tú ejecutas programas y lo ves como el sistema operativo lo va coordinando. El sistema distribuido también, o sea, van moviéndose distintos programas en la red. Las bases de datos también, o sea, te permiten tener todo tipo de informaciones. La propia base de datos te crea un sistema de cómo almacenar los datos en un computador o una red también. Y los lenguajes te permiten crear los programas, o sea, y eso para mí ya es como el sistema. Y ahí nace la idea de que por qué es importante entender compiladores, entender cómo se diseña un lenguaje de programación, porque una vez que lo entiendas, al menos tener una idea muy general de cómo es un compilador, te da otra perspectiva al escribir código de cualquier lenguaje de programación. Cuando tú tienes un fichero, este lo compilas o lo interpretas, ocurre esto, esto, esto, esto, ¿no? Que cuáles son las complicaciones de una sintaxis, porque una sintaxis más compleja requiere hacer un analizador sintáctico más sofisticado, en otro caso no, en otro caso sí. Bueno, ese tipo de cosas yo creo que abre mucho la mente, ¿no? Yo creo que el diseñar un lenguaje de programación una vez en la vida, aunque sea pequeñito, es un ejercicio mental extraordinario y te abre, yo creo que es el sistema quizás al menos que yo tengo más cercano a mi corazón, los lenguajes de programación es el corazón un poco de la informática, como decía Raymond Turner, la ciencia de la computación es un área dominada por lenguajes, todo, todo, incluso la parte más teórica de la computación son lenguajes matemáticos, lenguaje que es su propia matemática computacional. Pero todos lenguajes, lenguaje de programación, lenguaje de etiquetado, el lenguaje de comandos, hay lenguajes matemáticos como bien dije anteriormente, hay lenguajes visuales. Todo se basa en una cierta terminología y que puede ser escrita o con símbolos que nos permite crear esto que es computación, de sus más distintos tipos y sabores.

Y este tomo además lo cierras con un capítulo que se llama inteligencia artificial. Y esto me hace pensar, claro, porque al ponerlo como un sistema ya lo estás tomando como herramienta. ¿Qué opinas de este movimiento, de estas personas que mantienen que la inteligencia artificial llegará a la singularidad y a cosas incluso peores, y que no solo nos servirá de herramienta, sino que nos sustituirá?

Bueno, yo creo que en ese sentido no puedo decir ni sí ni no que eso ocurrirá o no, pero lo que sí puedo decir que en realidad, como anteriormente lo mencioné, lo más peligroso es la persona, los seres humanos. Al final, los que crean esa herramienta, quién va a tomar las decisiones, quién va a decir que esta ética es correcta o no, ellos son las personas que son más peligrosas. Yo no temo tanto a la tecnología en sí. Como al ser humano. Al final, todos los grandes problemas que hemos tenido han sido por personas, por ambiciones, porque tenemos cierta naturaleza que es tal cual, así como es colectiva en algunos aspectos, por otro lado es muy egoísta, individualista. Estamos llenos de defectos que todos los podemos tener, algunos un poco más, otros un poco menos, pero en algún momento surge, como emerge dada la circunstancia, y Y eso es la naturaleza humana, ¿no? Y si está entre medio el poder, el dinero, se pueden tomar decisiones que hagan que tecnología hagan cosas que no deberían ser. Y de hecho ya lo vemos en los militares, ¿no? Cuestiones, ya están ocupando inteligencia artificial, bombardeo con aviones autónomos, ese tipo de cosas. Y claro, hay temas éticos que se pueden trabajar, pero al final de cuentas los que van a tomar las decisiones, los que van a decir que esto se haga Incluso si asumimos que esto algún día va a ser como Terminator, no, o Skynet, todo ese tipo de cosas, en algún momento también un ser humano fue culpable de tomar ciertas decisiones para que eso se descontrolara, no. Entonces siempre está detrás del ser humano, no creo en una herramienta que sea totalmente autónoma y que tome conciencia y que nos va a desplazar. Yo creo que en realidad el más peligroso siempre es el ser humano, no. Y en cuanto a la singularidad No lo sé. Yo trato de ponerme una posición más neutra. No quiero ser un tecnófilo así que ama la tecnología y que esto va a ser siempre lo mejor, pero tampoco quiero ser un tecnófobo que siempre añora el pasado y ve como esto como un hype y no sirve de nada, y que siempre, bueno, está pensando en ese pasado que ya se perdió, ¿no? Entonces creo que hay que estar cauteloso y estar informado. Para mí eso es más importante, estar informado de lo que está ocurriendo y uno mismo sacar sus conclusiones, probar las tecnologías. En el streaming anterior yo recomendaba, que me decían, me preguntaban sobre qué recomendación le daría a las personas que piensan que pueden perder su trabajo con la inteligencia artificial. Yo le diría estar informado, o sea, si tú eres diseñador, infórmate qué herramienta de inteligencia artificial se utiliza los diseñadores hoy en día, úsalas, pruébalas, y o si eres traductor también Mantente informado. Y también hay que aceptar que en la vida, como todo, como si uno lee un poco la historia humana, siempre han habido carreras que han perecido, o sea, que han desaparecido porque se han transformado en otra cosa, se han combinado con otra cosa. Y eso es parte del avance de las sociedades, es inevitable prácticamente eso. Pero lo que sí puedes evitar es estar informado, estar prevenido. Y eso se logra leyendo, estudiando, escuchando entrevistas de gente experta en inteligencia artificial, ver lo que pasa para que si el día de mañana tu carrera desapareciera porque se automatiza, tú ya veías venir la ola, que ya estás ocupando cierta herramienta, y quizás tu profesión ya no va a ser la misma, pero va a ser diferente, no vas a ocupar herramientas que van a hacer tu trabajo y tú la vas a ir como a configurar, qué sé yo. Pero por eso es muy importante no ir en contra, decir esto, esto va. Hay gente que va como en negativa y dice esto no sirve, esto no sirve, y después la ola pasa encima de ellos y qué pasó aquí. Yo creo que eso es importante, por eso estar siempre informado de lo que está ocurriendo.

Pues me quedo ya con todas las dudas resueltas del libro. La verdad, vamos, le he hecho de momento la lectura rápida cuando lo compré, una lectura un poco más en profundidad de algunos de los capítulos. Bueno, puedo recomendar sin duda su lectura, incluso siguiendo cualquiera de las líneas marcadas. Yo empecé con la de la historia, me gustó más. Y bueno, lo recomiendo mucho porque es el primer libro que realmente te abstrae de lo que es los lenguajes de programación. Para los que ya somos programadores te da las bases, como bien habíamos dicho al principio. Y Camilo, ha sido un gusto tenerte hoy aquí en el programa y hablar sobre este tema tan interesante. Si quieres decir algo para finalizar.

Bueno, primero muchas gracias, Manuel, por la invitación. Bueno, a hablar de ese libro, que bueno, yo he publicado 4 libros, pero ese para mí es muy especial, ¿no? Por lo que dije anteriormente, que era un libro que resumía un poco el mi década de los 20, podríamos decir, la época de aprendizaje y maduración en cuanto a ser programador. Y tratar de haber traspasado un poco eso, creo que te haya servido. Y bueno, otras personas también me han comentado que le han servido quizá otros capítulos. Y así era un poco ese el objetivo, que a uno le guste más una parte, a otro no, otra parte más otra, porque era un poco un libro de libros. Al final esa es la idea. Y bueno, muchas gracias de nuevo por la la invitación y la he pasado muy bien. Y el tiempo pasó volando. Siempre cuando converso contigo o con amigos, no, que uno lo ve frecuentemente, siempre el tiempo pasa volando.

Pues hasta aquí el capítulo de Codeadores. Muchas gracias por habernos escuchado y nos vemos la semana que viene.