C#, SQL y F# con Héctor de León

Buenas, estamos en Codeadores otra semana más. Esta semana tenemos a otro invitado muy especial, otro Héctor, que viene a hablarnos. Bueno, yo le he hecho un poco la trampa y le he dicho que nos hable principalmente de C#, pero también bastante de SQL, que sé que es un lenguaje que le mola mucho. Al menos estuve viendo algunos desafíos que hizo en su canal de YouTube. Y en principio, a mí me gusta que los invitados cuando vienen se presenten. Pero además que conjunta la presentación responda a la pregunta de cómo fue que entraste en el mundo de la programación.

Vale, bien. Yo, fíjate que yo, bueno, los que no me conozcan, yo mi nombre es Héctor de León, soy de México, Guadalajara, México. Muchos piensan que soy de Ciudad de México, pero no, soy de Guadalajara, México. Este, fíjate que yo ya tengo un poco más de 20 años en la programación. Y obviamente yo creo que el tiempo se me ha pasado tan rápido que cuando te enteras y empiezas a ver para atrás dices cuántas cosas he hecho. Y fija, algo que me dedico, que no saben las personas, que yo sí me dedico a programar, sigo haciendo productos, este, y aparte que soy creador de contenido. Entonces parte de mi 30% de tiempo es crear contenido, mi 70% restante es programar. Afortunadamente todo diciembre yo lo tomo de descanso, así que en cuanto a programar, pero sigo creando contenido. Entonces nada más trabajo poquito, un pedacito. Y cuando yo, cómo llegué a la programación, es muy curioso. Yo en el 94, 92, no recuerdo qué año es cuando salió la película de Jurassic Park, pero más o menos 92 o 94, la primera vez que me llevaron al cine mis padres yo vi, este, una escena de Jurassic Park donde están cerrando las puertas por medio de un mouse y están los velociraptor siguiendo a los dos niños. Entonces a mí se me hizo tan interesante el ver cómo con botones en un mouse podía hacer manejar equipos como puertas, no, puertas electrónicas. Entonces yo dije, yo quiero hacer eso cuando sea grande. Y ese fue como mi primer acercamiento. Ya con todo el boom de Matrix fue fue como que el segundo acercamiento, porque ya era así como de, ah, todos queremos ser programadores, porque ya veíamos como que el concepto del programador ya con un poco de acción, y era como que no, no es estar nomás en la computadora, pues obviamente todo era ficticio. Pero yo creo que fue el segundo, la segunda vistazo que yo vi en cuanto al tema de la programación y todo lo que traía el concepto de Matrix, de mundo virtual y todo eso. Me adentró todavía un poco más. Y algo que no había contado es que yo también veía un anime que se llamaba Digimon, y también eso como que tenía que ver con programación de cierta manera porque era un mundo digital. Y eso también fue como que otro acercamiento. Y yo ya como a los 11 años me metieron en un curso de computación, de ver lo clásico, Office, PowerPoint, etcétera. Y yo veía que había otra, otra subclase que era de programación de analista. Entonces convencí a mis padres que me metieran a programación de analista porque ya había visto que eso podía hacer las cosas como en Jurassic Park, cerrar puertas. Y es donde me fue mi primer en la programación a los 11 años con Visual Basic 6, con Visual Basic Studio, Visual Studio 6, antes de que existiera .NET. Entonces yo, mi primer lenguaje de programación fue Visual Basic 6, y yo pensaba que la programación en ese entonces pues era tal cual como Visual Basic 6, arrastrar cosas, darle clic, agregar código, hasta que ya llegué a la universidad y me di cuenta que no existían cosas como C y cosas así. Y es donde ya empecé a asentar un poquito más mi base de programación. Pero así es como llegué a esta trampa.

Entonces, partiendo de Visual Basic 6 en la universidad, bueno, has dicho que ya empezaste con lenguaje C. Yo creo que la mayoría de gente que entró en la universidad sobre 2000, ese fue el lenguaje de programación que tuvieron que sufrir en la universidad. ¿Cómo llegaste de ese punto de Visual Basic C a C#?

Fíjate que ya yo, por ejemplo, hay una, yo empecé a trabajar a los 16 años, pero yo, hay un lenguaje intermedio entre C y Visual Basic 6 que yo vi que se llama PHP. PHP fue un lenguaje de programación que empecé a ver porque sonaba bastante en el 2002-2003, que es el lenguaje de la web, ¿no? Entonces tú empezabas a verlo y era junto con MySQL, o sea, era fuerza hasta aprender MySQL, y junto con HTML y JavaScript, que en ese entonces JavaScript solamente se utilizaba para cosas que eran animaciones y cosas así muy, muy básicas en el frontend. Y en ese entonces había ganado apenas la competencia con otros lenguajes como Visual Basic Script, etcétera, con Visual Basic Script, etcétera, que eran lenguajes que estaban compitiendo también en los navegadores como Netscape Navigator, etcétera. Y yo, ¿cómo llegué a C#? Fue porque en un trabajo, cuando ya estaba estudiando en la universidad, me contrataron y era hacer un proyecto de factorización electrónica aquí, la de México. Era como el 2008-2009 más o menos. Y vamos a hacerlo con C#. Yo no sabía C#, había visto algunas cosas de C#, pero no era como saber, no. Yo dije, diablos, bueno, pues a hacer lo mismo, pues el lenguaje de web, etcétera, no. Pero yo ya había visto Java también, algo Java yo ya tenía nociones por la universidad, que también te daban ciertos ejercicios, sobre todo la materia de compiladores y sistemas operativos, veíamos mucho Java. Entonces más o menos se me hizo muy parecido a Java, entonces no se me hizo tan complejo. Yo llego a C# gracias a que teníamos que hacer el proyecto de facturación electrónica y se prestaba mucho hacerlo con lenguajes de tipado fuerte como Java o C#, porque la facturación electrónica tiene una definición con algo llamado XSD. El XSD, tú con un comando puedes crear todas las clases porque tienen tipo, y esas clases ya creadas son muchas clases, no son 2, son muchísimas clases. Te ahorras toda esa parte de cuanto a la construcción de los XML porque ya tienen las clases para armar el XML. El XML, los que no tengan noción de la facturación electrónica, la facturación electrónica es un XML el cual se sella, se manda a una institución gubernamental, en este caso en México es el SAT, y esa institución lo que hace es verificar que tu factura sea real, esté sellada bien, etcétera, y la timbra. Y una vez que está timbrada, ya esa factura ya está, es válida. Se supone que ya es una factura que está validada por SAT, por lo cual es una factura real fiscalmente. Entonces este proceso empezó a ser obligatorio en el 2008-2009 y nosotros queríamos hacer un proyecto el cual se le vendiera a las personas porque era una necesidad que estaban haciendo. Y con C# se prestó bastante bien. Nada más que cuando yo hice la primera versión de ese sistema, parece un sistema hecho con PHP, o sea, parece un sistema que no agarra las cualidades fuertes de C# y es un sistema que parecía hecho como si, porque yo trabajaba con PHP, pues me basé en este tipo de manejo de PHP. Y después hice una versión nueva que es la que sigue trabajando hoy en día, que es una versión ya más pulida, con conocimientos más establecidos de C#, etcétera, etcétera. Pero fíjate que yo cuando llegué a C# se me hizo un lenguaje de programación como bastante adelantado a lo que yo había visto. A lo mejor, obviamente yo no había visto las mejores cosas avanzadas de PHP en ese entonces, o de Java, pero como la necesidad que era hacer la facturación electrónica, un proyecto grande para muchos clientes, Me hizo profundizar en el lenguaje y me gustó, la adopté, y es el lenguaje que ahorita hoy en día es el que más me gusta. Lo sigo utilizando, pero no necesariamente es el único que utilizo, pero sí es el que yo estoy al pendiente de lo que está saliendo, estoy al pendiente de sus nuevas mejoras, y sobre todo con la divulgación. Como creador de contenido es el lenguaje principal del cual yo divulgo. Divulgo de más, pero es el que sí es principalmente y por el cual la gente me conoce. Dice Héctor de León, C#.

Y viniendo de Visual Basic 6, sé que es bastante diferente porque pegaron un cambio de Visual Basic 6 a Visual Basic .NET. ¿No tuviste esa espinita de decir voy a probar Visual Basic .NET en lugar de C#?

Fíjate que alguna vez sí hice proyectos, sobre todo de hardware, con Visual Basic .NET y no se me hacía, o sea, no se me hacía algo tan difícil porque ya venía de, yo ya sabía Visual Basic, aunque no son iguales Visual Basic 6. Pero al momento que llegué a C#, se me hizo como una forma de trabajar más estructurada. El problema que yo tenía con Visual Basic, a lo mejor era en ese entonces era el único lenguaje que yo conocía, pero a lo mejor era, a mí me gustan los lenguajes con llaves. Entonces me di cuenta que me gustan los lenguajes con llaves al momento que empecé a ver C#. Entonces fue como que esa parte visualmente se me hizo más atractivo C#. Hay personas que no les gustan las llaves, estoy de acuerdo, como por eso les gusta Python, etcétera. Pero fíjate que aún así yo Visual Basic hoy en día yo ya no lo toco para nada, pero hubo una racha que sí lo tocaba para modificar ciertos proyectos de otras personas y no se me hacía complejo porque cuando estás trabajando con tecnologías que tienen la base de .NET son las mismas bibliotecas, entonces son los mismos nombres de las clases, los mismos métodos. Entonces no, no, no, nada más la sintaxis es diferente. Hay cositas muy, muy particulares de Visual Basic 6 o de Visual Basic .NET en cuanto al lenguaje, que sí a veces se te quedan tan grabadas que las quieres replicar en otros lenguajes de programación. Por ejemplo, el if-then, el loop-while, etcétera. Y yo cuando a veces me estaba pasando a otros lenguajes de programación, quería seguir poniendo el then y pues no, no, no iba el then. Y otra de las cosas también que se me hacían curiosas de Visual Basic era de que era un lenguaje de programación que tenía tanto auge, tantas personas que probaban en él. Pero pasó un fenómeno curioso. Bueno, el fenómeno sí lo conocemos. Microsoft ya no lo quiso, no le quiso dar mucho énfasis, pero terminaron todas esas personas, la mayoría, yéndose a C# porque pues ya no, siempre Visual Basic en cuanto a .NET iba atrás, se iba atrás, iba atrás, iba atrás. Salían nuevas cosas para C# y Visual Basic iba atrás, iba atrás. Entonces ese fenómeno yo creo que al final de cuentas fue lo que ocasionó que muchas personas terminaran en C# porque era un lenguaje que al final estaba dependiendo de C#. O sea, C# iba adelante con nuevos conceptos y Visual Basic no tenía esos conceptos o esas nuevas, nuevas cosas que podías hacer con C#. Por ejemplo, proyectos de internet de las cosas, proyectos de machine learning, Visual Basic no se podían hacer porque todavía no era compatible. Entonces siempre el hecho de ir atrás hizo que las personas se adentraran directamente a C# y olvidaran Visual Basic de cierta manera. Aunque yo conozco todavía muchas personas que trabajan con Visual Basic porque Hay tantos proyectos legados y de Visual Basic 6 que siguen existiendo programadores de ese tipo de lenguajes porque esos proyectos funcionan tan bien que no van a invertirle para que hagan el proyecto de cero. Y son proyectos muy interesantes porque yo he visto proyectos que trabajan con Visual Basic 6 con básculas que pesan tráileres, proyectos que trabajan con Visual Basic 6 que son impresoras que andan, impresoras de esas de imprenta que andan imprimiendo lonas. Que son proyectos que hicieron en los años 90 y están funcionando con máquinas enormes, y los drivers de ese momento a veces ya ni se actualizaron para esas máquinas. Y eso es como por ese proyecto funciona bien cuando no lo cambian de tecnología. Y esa gama es bien interesante porque son proyectos que últimamente yo ya no veo que se hagan tanto hoy en día porque ya están hechos sus proyectos. O sea, ya esas máquinas, eso es una máquina que te cuesta millones de dólares no vas a comprarte otra en muchos, muchos años. Y el software que hiciste en los 90 sigue funcionando. A lo mejor le están modificando cositas y necesitas un programador de Visual Basic 6, pero esos proyectos ahí siguen existiendo y dándole vida a Visual Basic 6, Visual Basic .NET. Pero el otro fenómeno es que las nuevas cosas, bueno, los programadores ya tienen que irse a C# casi obligatoriamente. Lamentable, afortunadamente, no lo sé. Cada quien puede tomar esto, pero sí fíjate que al final de cuentas Creo que el enemigo de Visual Basic fue el mismo Microsoft y el mismo, bueno, los avances de C#, que siempre lo iban adelante.

Y también sobre SQL, porque vamos a hacer que sacaste un vídeo en el que programaba un videojuego con SQL, que se sale un poco de su nicho, pero quedó bastante bien. ¿Cuándo empezaste con SQL y por qué? O sea, bueno, ¿Tuviste algún tipo de frustración iniciando con SQL? Porque es un lenguaje muy diferente a los lenguajes de programación normales. Y cómo ese amor por SQL, ¿qué te llevó, por ejemplo, a hacer ese vídeo?

Fíjate que SQL, yo llegué cuando en los años de PHP, en el 2003-2004, cuando me adentré a PHP, me adentré a MySQL. Y yo, fíjate que hay una anécdota bien curiosa. Yo sabía lo de SQL, lo básico, SELECT FROM, SELECT Sabía lo insert, update, delete, lo básico, no, las manipulación de data muy simple y consulta. No sabía crear objetos con SQL, no sabía seguridad con SQL, no sabía nada de eso. Yo simplemente hacía el típico CRUD con PHP y pues sabía lo necesario de SQL. Y fui a una entrevista de trabajo a los 16 años, 15, 16, y me dijeron oye, ¿sabes JavaScript? Y yo pues sí, no sabía nada de JavaScript, sabía una mierda. Y en la noche me puse a estudiar JavaScript Bueno, ya cuando llegué al trabajo me pusieron más SQL que nada. Y fíjate que me quedé con el trabajo, pero algo que me— ahí donde me di cuenta del potencial de SQL, me encargaron una de las tareas, era agrupamientos, pero yo no sabía que existía la sentencia GROUP BY. Porque te estoy hablando de un tiempo donde el conocimiento no estaba tan a la mano, el conocimiento tú ibas curioseando, ibas aprendiendo, pero no había como que creadores de contenido, divulgadores que te dijeran tienes que aprender esto, esto, esto, o existe esto, esto. No, tú simplemente ibas escarbando, ibas aprendiendo. Y el contenido en internet pues no era tanto como el de ahorita. Entonces yo no sabía que existía el GROUP BY. Yo todo eso de esa, esa, ese problema lo resolví directamente con PHP. Me puse a hacer un array que empezó a encapsular las cosas diferentes y luego meter los hijos en los que iba detectando con otro for y resolvió el problema. Y llega el tipo que me hizo el examen y hace un GROUP BY y lo resuelve en la misma línea de SQL. Y dije, diablos, ¿a poco se puede hacer eso? Y es cuando vi que SQL era muy potente. Yo más tarde llego a gobierno, trabajo a gobierno, y en gobierno toda la capa de negocio, que no hagan eso, toda la capa de negocio era SQL, todo era stored procedures con SQL. Entonces ahí es donde yo realmente aprendí SQL, porque era trabajar de lleno con SQL. Y PHP acá en gobierno solamente era como una capa que hacía solicitudes. El usuario metía un formulario, hacías la solicitud, ibas al stored procedure, le mandabas los datos Y esto procedió hacia todo y te regresaba la solución. Y donde vi el otro potencial de SQL, el gran lenguaje que estaba, más bien la gran tecnología que estaba gestionando información masiva, y cómo cuando trabajas esa información masiva local era muy rápida. Entonces ahí, cuando yo trabajé en gobierno, puede ser que fue un infierno de cierta manera porque yo no tenía la expertise para trabajar con el open source, pero al final aprendí bastante. Y es donde yo empiezo a ver SQL como un lenguaje mucho más avanzado. Junto, cuando trabajaba en gobierno, yo estaba estudiando en la universidad y estaba estudiando una materia que se llamaba lenguajes comparados, y donde veíamos lenguajes funcionales, este, que la parte declarativa. Y es donde empiezas a ver ese gran potencial que tienen los lenguajes declarativos, o esa, o el paradigma declarativo, que era cuando empiezas a ver SQL de esa manera, no tanto imperativa, lo empiezas a ver como una manera, como una abstracción arriba de la imperativa, una abstracción más cercana a lo humano, empieza a entenderlo mejor. Porque muchas veces también SQL, sobre todo en Transact-SQL, que en SQL Server tú puedes programar igual imperativo si quieres, tienes for, tiene, digo, tienes while, puedes hacer ahí un while directamente y hacer cosas imperativas. Pero el objetivo de SQL no es hacer cosas imperativas, sino que la misma consulta te resuelva la mayoría de cosas. Tú puedes en la misma consulta ordenarlo, lo puedes filtrar, lo puedes agrupar, y lo puedes limpiar la información y la puedes meter a una variable. Entonces la misma consulta, sin necesidad de una iteración, un bucle, puede hacer muchos procesos. Y ese es el potencial de SQL. Y es cuando yo entendí que los lenguajes de programación funcionales o declarativos, o que se asemejan más a la parte que es humana, son lenguajes de programación, o era un paradigma que se iba poco a poco a ver más. Y es lo que estamos viendo. Fíjate cuánto antes ni se hablaba de programación funcional. Hoy en día vemos programación funcional sobre todo en el frontend, ya se habla bastante sobre todo en el frontend, toda la parte que tiene que ver con reactividad o encadenamiento de funciones, programación funcional por todos lados. Y todo eso, si tú aprendes SQL, se te hace más fácil porque dices, ah, mira, es que aquí están haciendo un filter, ah, pues es un WHERE de SQL tal cual. Aquí están haciendo un map, ah, bueno, es una conversión de SQL, un SELECT FROM que estás convirtiendo la información, o sea, es prácticamente es el paradigma declarativo, tiene un gran potencial porque escribes poco para hacer mucho. Y es cuando yo dije SQL, wow. Yo, yo por eso me, yo me encanta SQL. O sea, yo sí también me pongo a hacer cosas extrañas como videojuegos con SQL. Obviamente sale del nicho, pero es para demostrar que SQL es un lenguaje de programación, porque muchas personas creen que no es un lenguaje de programación. Pero ahorita hablaremos de eso.

Nada, curioso, porque MySQL, como dices, es un lenguaje declarativo y muchas de las formas en las que se explica tiene ese carácter de composición, de incluso poner sus consultas y otra serie de construcciones. Y eso creo que es lo que está permeando ahora a otros lenguajes de programación. ¿Has terminado? Porque he visto muchos libros que sacan el tema de programación funcional con Python, programación funcional con JavaScript, programación funcional con lenguajes que en principio da la sensación de que no se puede hacer programación funcional. ¿Has visto este movimiento también en C#?

Fíjate que en C# hay algo curioso que pasa con C#. Si C# iba adelante de Visual Basic, F#, si conoces F#, F# es un lenguaje de programación funcional, va adelante de C#. F# es un lenguaje de programación funcional, yo lo poco que sé de F#, me ha encantado, pero se me hace un lenguaje de programación tan limpio, tan, tan, se puede decir, tan hermoso, aunque esté mal dicho, pero es tan limpio que ves esas cosas que puedes hacer con pipes, encadenamiento de funciones, en tan poquito código puedes hacer muchísimas cosas. Dices, diablos, lo que está pasando es que F#, yo lo veo de la siguiente manera, a lo mejor no lo real, pero yo así lo veo, y a lo mejor muchos programadores de C# lo ven así. F# es un lenguaje de programación que no se utiliza tanto, pero es un lenguaje de programación como para experimentar hasta nuevas cosas funcionales que se pueden pasar a C#. Y una vez que están bien probadas en C#, se van adoptando. Esto lo vimos a partir de la versión 9 de C#, que llegaron los récords, que los récords creo que nacen en Haskell, pero después en F# ya existían los récords. Los récords es una entidad inmutable La cual, bueno, pues te sirve para hacer muchísimas cosas, sobre todo con concurrencia, no, para asegurarte que la información inicial no se modifique. Y se modifica, creas un clon. De esa manera tú puedes rastrear dónde está cierto cambio de estado, porque cuando tienes elementos mutables pues es un caos buscar dónde se cambió algo. Entonces los récords llegan a C# gracias a F#, que fueron probados y fueron detectados que era una buena opción, y llegaron a C#. Ahora, en C#, fíjate que en cuanto a programación funcional tenemos toda una gama que se llaman delegados. Los delegados es una forma de hacer programación funcional tipada. Es decir, tú puedes especificar un tipo de función, es decir, este delegado va a ser un tipo que tiene una entrada de entero y una salida de entero. Entonces solamente puedes meter como parámetro una función que tenga una entrada de entero y una salida de entero. Entonces en C# particularmente pasa eso, como es un lenguaje tipado fuerte en la programación funcional no iba a estar de más meter tipado fuerte. Entonces, de cierta manera tiene sus pros y contras. Obviamente tardas más tiempo en definir la función porque tienes que definir su tipo de entrada, su tipo de salida y todo eso, que en lenguajes como Python que simplemente mandas la función y ya está, no, JavaScript mandas la función y ya está, no te preocupas por el tipado. Y acá en C# sí, pero últimamente con las nuevas cualidades que están, o más bien los tipos de proyectos que tiene C# como tipos de frontend con Blazor o el machine learning puedes hacer con C#. Se presta mucho la programación funcional, aunque muchos programadores, hay de todo, hay programadores que son de la vieja escuela en C# y siguen programando en C# como si se fuera a C# 2, C# 3, o sea, no, no se actualizan a las nuevas características o azúcar sintáctica que va teniendo el lenguaje. Pero hay programadores que sí están al día, y yo ya cada vez veo programadores que están utilizando más lo que es el tema de monads o el functores, etcétera, o entienden para qué es el objetivo de esto, ¿no? Y aunque hay programadores que dicen es que yo no utilizo programación funcional, sí la utilizan porque en C# hay una extensión llamada LINQ. LINQ es una forma, imagina que estás trabajando con SQL dentro de C#. LINQ sirve para colecciones y obviamente como sirve para colecciones y está basado en SQL, es un lenguaje declarativo, es una extensión que tiene C#. Puedes trabajar directamente con C# poniendo un from, un alias, select la colección, where, orderBy, groupBy, etcétera, y ya te regresa directamente en el mismo lenguaje C# el resultado. Y aquí dentro pues obviamente tienes programación funcional porque las funciones where, orderBy reciben una función de primera clase, por lo cual ahí está, tienes programación funcional aunque no la quieras utilizar, ahí la estás utilizando. Y LINQ es algo que sí veo que todos los programadores de C# utilizan porque es muy fácil, muy rápido, te ahorras for, te ahorras whiles, directamente con una consulta. Y se me hizo bastante buena propuesta de LINQ, porque es esa parte que tú dices, ay, me da pereza hacer, tengo que hacer aquí un ordenamiento, tengo que poner aquí un método sort, etcétera, etcétera. Y acá directamente la misma consulta lo ordena, lo filtra, lo agrupa, le haces un join con otra colección, etcétera, etcétera. Todas esas particularidades que tiene SQL dentro de C#. Y esto, si no lo saben las personas que están adentrándose en C#, métanse a LINQ, es una extensión de C# que ya viene en .NET, o sea, no tienes que instalar nada, ya está. Y también trabaja de forma asíncrona, que es otra cosa interesante, porque a veces esas colecciones tienes mucha información y puedes aprovechar el tanto asíncronamente como paralelamente, dependiendo tu situación. Puedes aprovechar los procesadores que tiene con tu computadora para hacer la manipulación de la data. Si tienes muchos procesadores, puedes hacer que esas consultas haga paralela, por lo cual se está haciendo un recorrido, se va a hacer de forma paralela y va a ser mucho más rápida. Entonces a mí se me hace, esa es una extensión que tiene LINQ que ya se llama PLINQ, LINQ. Así que fíjate que por eso es como que me gusta C#, que está agarrando muchas cosas. Es como los que vean Naruto, es como el Kakashi que está copiando cosas de todos lados, copia cosas de Kotlin, de Swift, de Haskell, y para bien. Pero muchos programadores lamentablemente no se ponen al día y siguen programando pues más código del que deberían de escribir Porque muchas de las cualidades de C# con los años ha sido azúcar sintáctica. La azúcar sintáctica es escribir lo mismo pero con menos código, y eso pues al final de cuentas es más legible, escriben menos. Aunque a veces la persona no sabe de esa azúcar sintáctica, se asusta, dice, ¿qué es esto? ¿Qué escribieron aquí? Pero son cosas que te obligan a actualizarte en el lenguaje de programación. Sobre todo, todos los programadores tenemos un lenguaje o 2 preferidos, o 3 quizás, y si son tus preferidos, pues actualízate en esos lenguajes, ¿no? Para que estés al día. Y sobre todo por tu bien, escribes menos código.

Buen consejo. Sobre los lenguajes de programación, ahora metemos un poco en la ecuación a F#. O sea, has comentado de las cosas que te gustan de estos lenguajes, de C# que tiene extensiones como la de LINQ, SQL que te facilita mucho hacer ese tipo de consultas, y quizás F# desde lo avanzado que está para probar cosas nuevas. Pero, ¿qué es lo que no te gusta tanto de estos lenguajes? O, ¿qué dirías, mira, esta parte me resulta siempre un dolor cada vez que tengo que utilizarla y la cambiaría o la salvaría de otra forma?

Yo creo que tiene que ver más con la plataforma .NET que el lenguaje mismo. El lenguaje, pues, al final de cuentas, las cualidades que a veces nos quejamos son el tipado, ¿no? Que es más tiempo tipar que poner simplemente un var y ya está, ¿no? Aunque hay una cosita que tiene C#, que quiero aclarar. Tiene un var, pero no es el var mismo de JavaScript. El var de C# es solamente un azúcar sintáctica para definir su tipo con lo de la derecha, pero sigue siendo tipado fuerte. En JavaScript pones un var algo y le pones cualquier cosa y le vuelves a convertir a cualquier cosa y pasa, no. En C# no. Ahí, en cuanto a la plataforma .NET, fíjate que en cuanto a la historia de .NET hay mucho desconocimiento. Las personas siguen pensando que tienen que pagar dinero por trabajar con .NET. Piensan que tienen que comprar una licencia y no es así. Lo que pasa que Microsoft empezó .NET Framework como un proyecto que no era código abierto y era un proyecto que regularmente para trabajarlo con Visual Studio había ciertas versiones de Visual Studio que había que pagar, como SQL Server. Pero con el tiempo se dieron cuenta que no era el camino, entonces crearon .NET Core. .NET Core es open source, no tienes que pagar nada. Hay una versión de Visual Studio gratis que se llama Visual Studio Community Como todo, hay una versión de paga que es la Enterprise, etcétera, pero tú puedes trabajar con Community. O de hecho tú puedes trabajar .NET directamente con Notepad. O sea, tú puedes Notepad y tienes un CLI, tienes una línea de comando para compilar, para correr. Tú puedes trabajar .NET como tú quieras. Si puedes trabajarlo con Notepad, puedes trabajarlo con cualquier cosa y gratis. O sea, no tienes que pagar nada. Entonces el desconocimiento de la gente entra porque piensan que .NET Framework es lo mismo que .NET Core. .NET Core es un .NET creado de cero y siendo open source. .NET Core empieza, termina en la versión 2, en la versión 3.2 creo, y empieza a llamarse .NET 5, .NET 6, .NET 7, .NET 8, .NET 9 ahora. Y muchas personas confunden eso porque .NET Framework, que es el que no es open source, se quedó en la versión 4.8. ¿Por qué se pasó .NET Core 3.2 a la 5? Para evitar esa confusión, para que no dijeran, ah, ese es el .NET Framework que se quedó en la 4.8, sigue la .NET 5 y es .NET Framework. No. Y pero al final yo creo que eso es lo que causa más confusión, porque en sí podríamos ver que hay 3 .NETs. El último es el que ya está numerado, simplemente no dice .NET Core ni dice .NET Framework, simplemente se llama .NET 5, 6, 7, 8 y 9, y es el que está hoy en día. Entonces a mí lo que no me gusta en cuanto a .NET es que cuando tú abres un proyecto de .NET Framework A veces no se tenía tampoco la madurez en cuanto a la paquetería, cómo se administraba. Hoy en día ya bajas simplemente el proyecto de GitHub y los paquetes se buscan y ya está, ¿no? Entonces, cuando abres proyectos viejos de .NET, y sobre todo que .NET Framework, y sobre todo en esa época también tú comprabas muchas bibliotecas. Por ejemplo, comprábamos la de Telerik, comprábamos DevExpress, etcétera, etcétera, y todas esas bibliotecas tienen un licenciamiento. Entonces abres un proyecto viejo y empieza a pedirte todos esos licenciamientos. Y eso es lo que a mí no me gusta, porque abrir un proyecto viejo es muy caótico. Y estoy hablando un proyecto viejo de .NET Framework del 2009, 2007. Y eso es lo que esa parte no me gusta. Y esto lleva a otra cosa que no me gusta: cuando tú hablas con una persona de .NET que no sabe de .NET, es confuso. Y las personas, yo por eso las entiendo, me dicen: es que tienes que pagar. No, es que no tienes que pagar, hoy en día ya es abierto. Porque se quedan con esa noción de que .NET era de Microsoft, era cerrado, etcétera, etcétera. Pero .NET ha avanzado tanto hoy en día, estamos hablando que ya lleva 10 años siendo open source, hoy 2014, casi 2015. Entonces, para programar en .NET no necesitas pagar nada, puedes trabajarlo directamente con tu editor que tú desees. Este, pero esa parte que a mí no me gusta es esa, todo ese cambio de versiones, de números, que hace que la gente, si tú quieres enseñar .NET, sea más confuso para las personas, porque las personas piensan Otra es una noción distinta de .NET, y la paquetería era un infierno. Y ahí te va otra cosa que no me gusta de .NET, que tiene que ver con eso, con ese infierno. Hay un ORM principal de .NET llamado Entity Framework. Entity Framework se tenía, se hizo la propuesta para trabajarlo como todos los productos de Microsoft, drag and drop. Tú arrastras, pones y se hace mucho código. ¿Dónde? Pues no sé, se hace mucho código. Había una propuesta antes de Entity Framework llamada DataSource. Datasets. Los datasets son una colección de tablas con las cuales tú también haces drag and drop, las unes, etcétera, etcétera. De ahí nace después el ORM Entity Framework. Tanto estas dos propuestas eran dos visualizadores, dos wizards que arrastrabas y se generaba código no sé dónde. Los que también han trabajado con NetBeans ya saben más o menos de qué hablo, que es un botón y se crea mucho código por ahí. El problema de esto radica que cuando tú instalabas Visual Studio nuevos, los wizards a veces no funcionaban ya con esas cosas. Entonces tú moverle a ese código que generaste de 80 tablas de Entity Framework, de 80 tablas de datasets, era un infierno porque se generaba mucho código de código XML, códigos no sé qué tanto, porque era pues era drag and drop. Esa posición que pusiste se tiene que guardar en algún punto, y esa posición que pusiste no tiene nada que ver con la programación, simplemente es para verse en esa posición. O esa flechita que pusiste también se tiene que guardar en un punto. Entonces era muy engorroso moverle a los datasets y a los Entity Framework en las versiones que te dan drag and drop en versiones nuevas de Visual Studio porque ya no eran tan compatibles. Eso estoy hablando de .NET Framework, eso también es un infierno. Pero a partir de .NET Core el Entity Framework ya no se maneja con drag and drops, ya simplemente es con código. Tú puedes trabajarlo con Code First, creas todas las clases y ya haces que se refresque la base de datos y se vea la base de datos como tus clases. O puedes trabajar database first, haces la base de datos y reflejas todas las clases en tu proyecto. Nada de drag and drop, simplemente ya es código puro de C#, ya está. Y eso yo creo que es una gran mejora, a pesar que muchas personas se acostumbraron. Yo entiendo que vienen de Visual Basic, están acostumbrados a drag and drop, doble clic, etcétera. Entiendo que esas personas se frustran porque piensan que vamos para atrás. Pero hubo ciertas problemáticas, sobre todo cuando tenías proyectos que ya tenían 10 años y quieras abrirlo y tronaba todo y era un caos buscar bibliotecas, todo eso. Pero hoy en día ya no pasa eso con las nuevas versiones. Esas son las cosas que no tanto es del lenguaje C#, sino que son los entornos de trabajo los que sí me frustra. Y en algún punto sí dije, ¿qué es esto? Allá me quiero ir a JavaScript, no sé, quiero irme de aquí.

Ay, siguiendo tanto como sigue la tela un poco de C# para JavaScript, Bueno, JavaScript no, perdón, es F#. Y SQL, no sé si estás al tanto de los últimos cambios. La última creo que fue la del pipe operator, que dicen que seguramente en la siguiente edición de SQL lo agreguen. Y entonces ya muchos motores de base de datos están viendo para hacer modificaciones y poner que la consulta pueda poner cada parte en un orden diferente.

Fíjate que hay otra cosa que hablas muy interesante de SQL. Y fíjate que dentro del estándar, a veces las personas se les olvida que los estándares cambian, ¿no? Y a mí me dicen, a veces me decían, no, es que eso no es el estándar de SQL. Y les digo, eso entró en el 90 en el estándar de SQL. De los estándares, lo que no sabe mucha gente, que SQL nace en los 70s, este, basado en una, en lo que estaba haciendo IBM. Y lo que no sabe la otra parte es que uno de los creadores de SQL se muere el mismo año de que sale SQL. Lamentablemente en el 74. Y pero SQL todavía no tenía un estándar. El estándar llega hasta los 80 porque vieron que era una tecnología que se iba a quedar. Y llega a los 80 y empieza a tener nuevas cosas cada estándar. No llega a los 90, se empieza a meterle programación sobre todo el tema de los procedures, variables, funciones, todo esto. Y SQL hoy en día sigue, sigue cambiando. Yo me quedé la última versión, yo no he leído las nuevas, los nuevos cambios. Pero siempre los nuevos cambios involucran cosas interesantes. Por ejemplo, antes hubo una cosa muy curiosa, que los motores, los gestores como MySQL, SQL Server, etcétera, se adelantaron un poquito al estándar metiendo JSON directamente, JSON, porque veían que había ciertas, pues había necesidades que a veces necesitas una columna que no tuviera forma, no, de meter cualquier cosa ahí y ya está, y no hacer una tabla para hacer todo eso. Entonces metieron JSON y en el estándar entró JSON creo que en el 2021. Entonces JSON ya es parte del estándar, para bien o para mal, no lo sé, cada sabrá si es para bien o para mal, pero entraron junto con él funciones que pueden leer JSON. O sea, tú ya simplemente haces el SELECT FROM y metes ahí una función para leer el JSON, lo puedes desguazar, no, lo puedes separar. Entonces, esto nuevo que me dices también se me hace interesante. Fíjate que no he leído sobre, sobre estos nuevos cambios, pero esto, a final de cuentas, todos esos cambios son necesidades que han visto que necesita el lenguaje, y eso pasa con todos los lenguajes de programación. Los lenguajes de programación, a veces yo lo veo que tienen odio por PHP, no, ay, que está horrible. Es que no has visto que PHP ha cambiado mucho a través de los años, siguen metiendo cosas nuevas a partir de necesidades. Los lenguajes de programación van evolucionando y mutando por esas necesidades, y uno de ellos pues es SQL. Y lo que voy con SQL, a mí lo que nos hace tan interesante es que es un lenguaje tan viejo que si lo comparamos con C#, con Java, SQL es mucho más viejo, o sea, es un lenguaje que tiene una evolución más grande, que empezó para hacer consultas de base de datos y todo, pero se ha hecho un lenguaje tan, tan único. O sea, si tú lo comparas con algo, no se parece a algo, en parte a otro lenguaje y en parte otro, pero es un lenguaje tan único que no hay una alternativa. O sea, no hay algo tan fuerte que digas, aquí vamos a utilizar otro lenguaje de consultas. No existe algo tan fuerte, que existen obviamente, pero no existe algo tan fuerte que pueda competir. Pues por ejemplo, como los lenguajes de programación que son para backend, ah no, pues lo podemos hacer en PHP, esto en C#, o en Python. Tienes muchas opciones, pero en cuanto a bases de datos relacionales, pues siempre SQL, ¿no? Obviamente vas a trabajar con una mutación, ya sea PL en Oracle, vas a trabajar con transacciones SQL en SQL Server, pero su base es SQL a final de cuentas. Y las personas que piensan que a veces se infravalora SQL, se cree que SQL solamente es para crear consultas, para manipular data, y se les olvida toda la parte que tiene que ver con transacciones, que tiene que ver con seguridad, que tiene que ver con creación de elementos. Y sobre todo la parte de seguridad es súper importante porque muchas personas a veces, hablando un poco más de lo que tiene el potencial de SQL más allá de lo que es manipulación de data, Las personas a veces dejan, y eso te apuesto que muchos los que están escuchando hoy en día ahorita este podcast, muchos lo hicimos, pusimos el usuario de producción que tenga acceso a todo. O sea, pusimos que te da permiso de todo y lo pusimos en producción, el usuario de la base de datos. Cuando tu sistema en producción no tiene por qué tener permisos de crear tablas, de borrar tablas, de hacer vistas, etcétera. ¿Por qué le vas a dejar esos permisos al usuario de producción cuando tu sistema backend no hace esas operaciones? Aquí lo que hago es un llamado para entender que SQL también tú puedes limitar lo que va a ser tu sistema desde el SQL. Es decir, este usuario, esa producción, solamente va a manipular data, pues déjale solamente esos permisos. Porque el día que te hackeen y te roben ese usuario, si no tiene permisos de crear tablas y borrar tablas, no va a ser tan drástico. A que te da el permiso de borrar todo. Entonces hay que, sobre todo hay sistemas que hacen borrado lógico, no hacen borrado físico. Entonces, ¿para qué le dejas el permiso de delete? Entonces, de esta manera vas protegiendo la información. Y obviamente pues también hay que agregar los backups. Muchas personas no hacen backups. Un sistema que se ha vulnerado, pues un producto que se haya utilizado por muchas personas y no esté asegurado con backups, o no esté asegurado para una situación drástica, se puede ir a la quiebra y tu producto se puede morir. Entonces hay que tener mucho cuidado con eso, y SQL también es una herramienta que te puede ayudar en esta, en esta parte. Y a veces lo infravaloramos a solamente hacer SELECT, INSERT, UPDATE y DELETE.

La verdad que gran consejo, porque es verdad que el tema de los backups, creo que cuando se quemó el data center de OVH aquí en Europa, muchos se arrepintieron de no tener las copias de seguridad en otro sitio. Otro tema, hemos estado hablando de las partes así de los estándares, lo que tiene el lenguaje y demás, pero ¿qué echas tú en falta cuando estás programando con este tipo de lenguajes que dices, oye, pues este lenguaje le vendría bien esta característica que no sé, puede ser de otro lenguaje o simplemente algo que ves tú que es un atajo que tienes que hacer mucho o que ves que no se puede hacer de una cierta forma fácil y al final dices, oye, pues si tuviese la posibilidad haría esto?

Fíjate que en cuanto a SQL, a mí ahí existen, por lo menos en Transact-SQL tenemos un tipo tabla, y eso es un, es una semejanza a los arrays. Pero en cuanto estás trabajando con MariaDB o MySQL, no necesariamente tienes ese tipo tabla. Puedes crear tablas temporales, pero hay que eliminarlas, etcétera, etcétera. A mí me hace falta como que esa parte de tener un tipo array, o sea, un tipo lista. Un tipo de dato que en los stored procedures hablo, porque a veces se necesita. Y ese tipo lista que se borre en automático, tal cual como las variables mismas, no, no que crees una tabla temporal y luego de repente metes la información y luego, ay, se me olvidó eliminarla y ahí está en memoria. O sea, no, eso es lo que yo creo que en SQL hace falta, aunque ciertos lenguajes como Transact-SQL ya lo tienen, que en Transact-SQL es el de SQL Server. Tiene un tipo table que puedes ponerle la especificación tal cual. Es un table, tiene un entero, es un primary key, etcétera, etcétera. Y esa, y esa la puedes meter en una variable. Otra de las cosas que hacen falta en los estándares es poder crear tus propios tipos en cuanto a SQL. Y cuando hablo de tipos es algo que tiene también Transact-SQL. ¿Por qué digo en el estándar? Porque hay gestores que no tienen tipos. Los tipos, tú creas un tipo y en el tipo ya especificas toda como una clase de programación orientada a objetos, tú especificas su estructura. Tú especificas, este es un tipo entero, tiene un tipo VARCHAR que se llama name, tiene un tipo entero que se llama edad, etcétera. Y ese tipo tú ya lo puedes estar reutilizando en tus stored procedures. Tú ya no tienes que estar definiendo el tipo tabla con la misma estructura, simplemente le pones el tipo, tipo people, y ya está, ya tiene toda la estructura. Entonces son las cositas que hacen falta, yo creo, es darle más énfasis al tipado en los stored procedures. Pero hay mucha gente que le tiene miedo a los stored procedures, y los stored procedures como que se han quedado de cierta manera estancados por ese miedo que tiene la gente a los stored procedures. Los store procedures no son para negocio. Los store procedures sirven para cuando tu RM de tu consulta se queda lenta y el store procedure puede ser una alternativa para que puedas probar si es más rápido todo centralizarlo en el gestor. Y también te sirve para tema de reporteo o tema donde tienes que limpiar data. Y no estoy hablando de modelos de reglas de negocio, porque siempre cuando escucha la gente de store procedure dice, no, las reglas de negocio no tienen que ir a la base de datos. No estoy hablando de reglas de negocio, estoy hablando de store procedure nada más. Store procedure no sirven Solamente para reglas de negocio. Mucho lo que tiene que ver con machine learning, hay muchos procesos que son limpieza de data. La limpieza de data es porque a veces las fuentes de la información que se sube a la base de datos no viene limpia, viene un Excel. Hay un problema bien clásico en SQL que las personas que tenemos unos añitos en SQL podemos notarlo o nos ha pasado. Tú pasas información de un Excel a una tabla, haces un WHERE del nombre de la persona Y no te llega.

¿Por qué no llega?

Resulta que ese nombre entre los apellidos trae un carácter invisible que viene desde Excel, y ese carácter invisible muchas veces es un space que no es el espacio del keyboard, es un espacio que existe en el Unicode, es otro espacio, otro tipo de espacio que es un poco más largo, pero tú lo ves igual. Ese problema es bien típico y son los problemas cuando hablo de limpieza de data. Cuando tu fuente de información es un archivo que viene de un sistema de los noventas, un DBF, un Excel, muchas veces tiene caracteres raros y esos caracteres se pueden limpiar en SQL cuando están haciendo la inserción. Caracteres que puedes limpiar con expresiones regulares. Dices, yo solamente permito de la A a la Z espacio normal, de la A a la Z grandes números, etcétera, y todo lo demás bórralo. Y eso se puede hacer con SQL, limpieza de data. Hay muchas personas a veces la limpieza de data Sobre todo personas que no están tan acercadas a lo que es manipulación de información, nunca les ha pasado, pero es una parte que puede ser con Store Procedures en automático. Y la otra cosa, la automatización, que es un proceso que hace que tus sistemas tengan vida cuando no hay usuarios. Tú haces procesos de limpieza de la información de las bases de datos. Por ejemplo, tienes tablas que tienen información, que esa información nomás la guardaste tú, un carrito temporal, un carrito de compras. Pero el carrito ya se hizo una orden, y a lo mejor esa información de ahí nomás te está estorbando de los carritos que hicieron en el 2009, que ya ni siquiera te interesa esa información. La persona no va a venir del 2009 a comprarte ahorita en 2024. Ese carrito pues lo vas borrando, ¿no? Todo ese tipo de cosas también se hacen con Store Procedures, los automatizas y los ejecutas a las 3 de la mañana y limpian toda esa información para que tu base de datos no crezca exageradamente con información basura. Ahora fíjate que en cuanto a C#, Yo creo que el lenguaje de programación ahorita ya me tiene bastante contento, por eso sigo trabajando con él. Pero hay unas cositas que sí echo de menos de repente, que se pueden hacer en cuanto los programadores de JavaScript saben que en JavaScript puedes crear objetos dinámicos, objetos anónimos directamente, y meterle funciones. O sea, tú creas la llavecita abertura, creas los atributos, las propiedades, nombre, no sé, tanto, tanto, tanto, y puedes crear un function y ponerle un comportamiento. Eso en C# no se puede hacer. En C# tú puedes crear objetos anónimos, pero no tienen comportamiento. Y tú me dirás, es que eso es todo lo contrario a C#, por el tipado, etcétera. Sí, pero hay cosas que a mí me encanta hacer, sobre todo el área de investigación, que cosas de ese tipo de dinamismo, ese tipo de versatilidad, te sirven bastante, sobre todo cuando estás haciendo metaprogramación, que la misma metaprogramación cree comportamientos. Entonces el hecho de que esté tipado te bloquea trabajar con elementos anónimos porque no puedes meterles funcionamiento. Entonces simplemente puedes crear objetos, estructuras de datos, pero no puedes meterle comportamiento. Es la parte que yo en C# sí echo de menos de JavaScript, lamentablemente. Pero, pero es cuanto a área de investigación. En sistemas no te sirve mucho eso porque pues es un comportamiento muy metaprogramático, o sea, un comportamiento muy dinámico para algo que tu sistema a lo mejor pues está fijo, ¿no? Pero a mí me gusta mucho estar haciendo cosas de investigación, sobre todo ahorita que tienes las APIs de GPT, de OpenAI, etcétera. Y les estás ahí así jugando, no, jugando. Tú sabes de jugar con código, no, que te gusta estar jugando. Y a veces me siento limitado por eso. Hay un tipo de C# llamado dynamic que se define hasta la ejecución. Tú puedes ponerle pato.nombre y si pato.nombre no existe va a compilar, pero la ejecución va a tronar. Ese dynamic puedes hacer cosas dinámicas, pero sí tiene una limitante sobre también con los comportamientos. Y eso es lo que me hace falta a mí, como que tener esa posibilidad de poder crear objetos anónimos con comportamiento, no solamente estructura de datos sino también comportamiento. Pero es algo mío, es algo que tiene que ver con investigación, y muchos programadores de .NET pues son más tipo empresariales, CRM, entonces no necesitan eso, o sea Por eso no se ha hecho, yo creo. Pero sí son cositas que sí de repente extraño de Python y de JavaScript.

Creo que quizás en F# ya están haciendo los primeros avances en este sentido, porque las funciones de primera clase son siempre algo bastante funcional. Así que quién sabe, lo mismo en el futuro ya tiene esa característica.

Sí, fíjate que quería decir otra cosa de C#. Se puede hacer de cierta manera con algo llamado árboles de expresión, pero es complejo, o sea, es mucho código. Los árboles de expresión es como está hecho LINQ, y es gracias a esa magia de los árboles de expresión, es prácticamente crear operaciones por medio del código que se van a ejecutar cuando tú las compilas, se ejecutan. Entonces, gracias a este potencial de los árboles de expresión que tiene C#, puedes tú convertir código de C# a SQL, y por eso LINQ trabaja, por eso los árboles de expresión, y podrías utilizar eso también para hacer metaprogramación, pero no es tan fácil. O sea, es mucho código, es tedioso, hay que meterte a funciones del compilador. O sea, ya sabes que cuando te metes con funciones de compilador son nombres extraños. O sea, y eso, o sea, al final de cuentas, porque C# no es un, no está hecho para propósito de ese tipo, pues, porque a lo mejor con C y C++, que está más acercado a lo que es el, la máquina, puede ser de cierta manera puedes manipular más este tipo de programación. Pero lenguajes que son interpretados, pues al final, porque como son interpretados puedes hacer este tipo de programación, metaprogramación, sin tanta restricción. Pero sí, con árbol de expresión se podría hacer, pero es tedioso, la verdad es tedioso. Y bueno, los que saben de árbol de expresión me entenderán.

En ese sentido, yo tenía que enfrentarme bastante a eso, y la verdad que te puedo dar la razón de que armar un árbol para recorrerlo y y generar código a partir de ahí no es fácil. Y dependiendo del lenguaje, pues ya como tú dices, C# tiene subtipos y está bastante restringido en lo que te permite hacer. Así que la reflexión estará un poco limitada ahí de qué es lo que puedes llegar a terminar haciendo y qué no. No es recomendable.

Sí, fíjate, ese tema de reflexión que hablas, que muchos programadores no saben qué es reflection. Reflection es la cualidad que tiene el lenguaje de programación para verse a sí mismos. Entonces tú tienes un objeto y el objeto tiene ciertas propiedades, y tú puedes hacer un for por las propiedades porque te puedes ver a sí mismo. Y sí, también tú puedes hacer reflection con C#, pero sí está de cierta manera limitado. Yo, porque me he puesto a, he querido sacar vídeos donde quería hacer cosas mágicas con C#, etcétera, y el vídeo quedó a medias porque no, no me restringió, o sea, no llegué hasta donde quería llegar. Cosas que con Python sí he podido. Pero fíjate que hay una cosa que sí puedes hacer con IronPython, es una biblioteca de C#. Puedes poner código de Python en C#, tal cual así, código de Python lo ejecutas en C#, y esa es como la posibilidad también que puede ayudarte. Python es muy dinámico y tú me dirás, oye, pero pues mejoralo en Python. Bueno, pues sí, pero a lo mejor tú tienes un sistema hecho en C# y que necesita solamente una partecita, ¿no? De metaprogramación. No sé, un reporte que tenga cualidades extrañas que piden los clientes y necesitas metaprogramación para hacer las columnas según, dependiendo ciertas reglas de negocio. Este lo puedes utilizar con IronPython. Son cualidades que a veces las personas no conocen en los lenguajes de programación, que al final son herramientas que pueden jugar en conjunto. Tú también con lenguajes de programación cualquiera puedes ejecutar un lenguaje de programación X directamente con línea de comandos. Al ejecutar línea de comandos le mando los parámetros, el famoso el famoso este main con args, el array que tienen, no, o sea, le mandas argumentos y el lenguaje de programación se encarga de resolver y te da una respuesta, un return, y ya tú ya lo, ya juegas con eso, no. Y eso, la programación así es, al final de cuentas son funciones que les mandas valores que te retornan un valor, a veces no. Y eso también tú puedes jugar con lenguajes de programación directamente con línea de comandos. Y a veces las personas no conocen esa parte, y por eso hice un poquito de énfasis que tú puedes Decirás que esto sí lo puedo hacer con este lenguaje de programación, pero solamente necesito una parte. Bueno, pues haces esa parte en ese lenguaje de programación, lo pones en tu servidor, lo ejecutas por línea de comandos y ya está. Es invisible para el usuario.

Y desde el punto de vista de aprender este tipo de lenguajes, o sea, porque hemos dicho ya un lenguaje funcional como F#, un lenguaje imperativo y orientado a objetos como C#, un lenguaje declarativo como SQL, incluso lenguajes de scripting que vamos mencionando de vez en cuando, como PHP, Python. Si tuvieses que recomendar a alguien que quiere iniciar en el mundo de la programación, ¿cuál sería tu recomendación?

Fíjate que yo, las personas se abruman si no ven cosas. O sea, está bien la consola, no ves la consolita, mi programa, mi expendedor de dinero, mi cajero automático, no existe el programita, ya le meto, quiero 5 pesos, o sea, 2 y una, tienes 2 de 2 y una de 1, no. Pero las personas les encanta ver cosas y yo creo que el motivante de ver cosas te ayuda, te hace adentrarte un poco más. Yo la verdad, mi recomendación es que empiecen lamentablemente con JavaScript porque ya pueden ver las cosas sin instalar nada. Y esto lo digo mucho a las personas que no tienen conocimiento alguno de programación, porque el hecho de que tú abras el navegador modifiques en Notepad algo y metas HTML, CSS o JavaScript y se esté ejecutando, ya te da motivación. A veces veo que las personas se quedan en el instalador, dicen, ah, tengo que instalar eso y tengo que instalar esto otro. Ahora, no digo que JavaScript sea el mejor lenguaje de programación para aprender a programar, pero ese es el lenguaje de programación que se presta, gracias a sus características que trabajan en el navegador, a que las personas puedan dar el inicio, adentrarse a la programación y ver cositas, ¿no? Ahora, ya cuando tú quieres adentrarte a conceptos fundamentales de la programación, yo ya te sugiero meterte un lenguaje de programación tipado, porque a la larga esa curva de aprendizaje extra que tienes en el tipado, las interfaces que tienen lenguajes como Java y C#, es algo que no te vas a poder brincar. O sea, al final de cuentas, cuando ya estés trabajando en una empresa, o sea, una empresa que esté trabajando con arquitecturas escalables, Muchas veces entender conceptos como de interfaces, programación orientada a objetos, tipado fuerte, te puede ahorrar bastante, bastantes problemas. Y son conceptos que tienes que aprender aunque tengas lenguajes de programación no tipados, son conceptos que vas a necesitar porque al final JavaScript tú puedes medio tiparlo, le puedes darle un tipo a las cosas y reducir las problemáticas. Pero eso tú lo vas a, ya lo podrías saber si empezaste a aprender ya un lenguaje como Java, un lenguaje como C#, o hasta C++, aunque yo te sugiero mejor irte directamente con C# o Java. Ahora, esta es una recomendación mía porque muchas personas se abruman porque dicen es que es más difícil aprender estos lenguajes de programación. Sí, pero te van a acercar más rápido a esos conceptos que te van a preguntar en una entrevista técnica. Y en una entrevista técnica te van a preguntar por cosas que el hecho de que estás aprendiendo fundamentos de C# lo estás viendo desde el inicio. Y a lo mejor con JavaScript no, porque en JavaScript directamente instálate el framework React así, pero no entiendes nada de JavaScript, nomás estás ejecutando comandos. Y luego resulta que solicitudes, esto ejecuta el backend, sí, y no entiende nada de solicitudes HTTP. O sea, y eso cuando tú llegas a una entrevista técnica son cosas que te van a preguntar. No te van a preguntar cuál función utilizas para ejecutar una solicitud HTTP en JavaScript, no te va a preguntar a ver HTTP ¿Cómo lo manejas? ¿Qué pasaría con esta situación? Cuando te regresa un código de error este, ¿qué significa? O sea, este tipo de cosas es adentrarte directamente a los fundamentos. Por eso yo lo que siempre les he dicho a las personas: métanse a los fundamentos, no importa el lenguaje. Pero mi sugerencia es que C# o Java te van a llevar a esos fundamentos directamente, y esos conceptos fundamentales son conceptos fundamentales que se van a aplicar en cualquier lenguaje de programación. No es que sean propios de C#, no es que sean propios de Java. Y vean el lenguaje de programación como una herramienta para implementar los conceptos. No lo veas como una herramienta que tiene ese concepto egoístamente solo para ella. No, el concepto se replica en muchas partes, y si tú aprendes el concepto con el lenguaje de programación que sea, ya no tienes que reaprenderlo. Simplemente lo vas a implementar con el otro lenguaje de programación, a lo mejor de otra manera, pero el concepto en tu cerebrito ya lo tienes bien aprendido. Dices, esto sirve para esto, y cómo lo escribas ya es lo de menos. Ah, tengo que escribir esto, esto para hacer ese concepto, está bien. Por ejemplo, hacer que un elemento sea inmutable, no trabajas con JavaScript, va a ser más complejo que hacerlo con, bueno, puedes poner un const, pero no, eso no evita que sea fuertemente inmutable. Pero en C# tienes ciertas herramientas para hacer inmutabilidad, en Java tiene ciertas herramientas para hacer inmutabilidad. Pero de hecho, que entiendas qué es inmutabilidad ya es un paso extra para que digas, oh, aquí JavaScript se puede complicar la inmutabilidad, ¿qué tal si usamos TypeScript? Entonces ya tienes como que Puedes tomar decisiones, pues, y ese es el objetivo de lenguajes de programación que tienen una curva de aprendizaje más grande, saber conceptos que al final de cuentas tienes que aprender. O sea, no, no hay atajos, tienes que aprender las cosas tarde o temprano.

Es curioso que muchos lenguajes que son muy difíciles de aprender, como Rust o Haskell, se idealizan. La gente los pone como los lenguajes en los que les gustaría trabajar y trabajar y aprender más en profundidad, pero realmente ninguno se lanza a ello.

No, es que estás hablando de Haskell. Haskell es un lenguaje de programación, de lo poco que yo he visto, es que son lenguajes de programación que son puramente funcionales. Y si tú vienes ya con una noción de lenguajes imperativos, es muy difícil que lo aprendas de una, de inicio, porque por ejemplo directamente tienes composición de funciones y tienes de repente, creo que no tiene tipado, no, Haskell no tiene tipado, o no, a lo mejor ya lo tiene, no sé si tiene tipado. Tiene tipo, pero te metes a conceptos que a veces tú, que puedes replicar el lenguaje de programación que estás utilizando, no todos, pero sí muchos. Pero al final de cuentas no es la forma como estás trabajando tú regularmente, y por eso se les complica a las personas. Pero Haskell, al final de cuentas, son lenguajes de programación de los más pagados. Los lenguajes funcionales son los más pagados si los ves en las estadísticas de Stack Overflow. Pero es por eso, porque mucho programador dice yo quiero trabajar con ellos, pero nunca se adentra, les da miedo.

Y ahora que saca el tema de trabajar con ese tipo de lenguaje, ¿cómo ve el mercado laboral si quisiera dedicarme a F#, C# o incluso exclusivamente con SQL? ¿Podría ser posible?

Yo creo que SQL sería posible solamente en donde se haga mucho más lo que sea machine learning o ciencia de datos, entonces ingeniería de datos, porque ahí sí hay que meter SQL por todos lados. Pero regularmente F#, cuando me dicen oye, F# tiene los mejores sueldos o tiene unos sueldos muy altísimos, sí, pero la, la, el número de vacantes es muy pequeño. Y si tú quieres trabajar con F#, yo te sugiero que trabajes con C# primero, porque F# es un lenguaje de programación que al final de cuentas no vas a encontrar tanto, o sea, es muy difícil que encuentres un trabajo. Si lo encuentras, va a ser muy bien pagado, pero va a ser en empresas de investigación, empresas, la misma Microsoft, o sea, empresas grandes, que obviamente es una buena opción para decir, o sea, es una opción como alternativa, que yo la vería como una alternativa. Aunque aprender F# y ve viendo qué cosas, qué cosas, y podrías toparte con una vacante muy interesante, pero no lo vería como la opción principal. Yo mejor te recomendaría aprendes C# porque C# tiene muchísimas vacantes, sobre todo en sistemas empresariales o empresas grandes, empresas que digo sistemas que son grandes. Y C#, el lenguaje de programación como tal, no solamente te va a permitir trabajar con sistemas empresariales, sino que C# junto con .NET tú puedes hacer proyectos de todo tipo. Puedes hacer frontend con Blazor, puedes hacer backend con ASP, que ASP tiene muchas, muchas variantes. A veces las personas se quedaron con el ASP viejo. No, ASP tiene una forma de trabajo con una arquitectura MVC, que es una arquitectura que se hizo famosa en el 2010. Ahora ASP tiene, ya puedes trabajarlo directamente con minimal API, que es muy parecido a Express pero con tipado. Express de Node.js. Puedes trabajar ASP junto con Blazor y con una arquitectura muy interesante en la cual tú puedes combinar con WebAssembly. Blazor se puede cargar con WebAssembly y ya directamente la primera vez va a ser tardado, pero las siguientes veces va a cargar súper rápido y puedes hacer que procesos no necesiten internet porque el WebAssembly ya los va a tener cargados. Este, puedes trabajar machine learning aunque no se trabaja tanto con C#, pero se puede hacer. Puedes trabajar internet de las cosas. Puedes trabajar videojuegos con Unity, que eso está sonando bastante. Puedes trabajar aplicaciones de escritorio con Windows Forms, Windows Presentation Foundation, y puedes trabajar aplicaciones híbridas, que es todo lo que tiene que ver con celulares, con algo llamado MAUI, que es la evolución de Xamarin. MAUI es como un Xamarin 3, el cual ya puedes trabajar también aplicaciones de escritorio y puedes combinarlo junto con Blazor. Entonces son muchas alternativas que puedes trabajar con C# y muchas empresas La mayoría de empresas saben, saben que están esas alternativas, pero fíjate que los trabajos que más vas a encontrar van a ser de backend. O sea, de backend en C# vas a encontrar bastantes. Así que mis consejos, si quieres algo de las 3 opciones, métete a C# y SQL porque van a ir de la mano. Y si quieres meterte a SQL ya de lleno con C#, métete a Transact-SQL, que es casi lo lógico que vas a encontrar, C# con SQL Server. Entonces métete a esas 2 cosas. Porque vas a ir al backend, cae seguro, al backend con C# o aplicación de escritorio viejas, porque también hay mucho de eso. Hay muchas aplicaciones de escritorio, lamentablemente son .NET Framework, pero trabajo sí hay, trabajo y bastante. Pero como siempre digo, al final de cuentas, dependiendo tu localidad, tú ve tus trabajos que están en tu localidad. Y si tú eres un programador de cierto lenguaje de programación y ves que hay otros trabajos que son bien remunerados en otro lenguaje de programación, que no te dé miedo empezar a ver ese otro lenguaje. No te va a costar tanto trabajo cambiarte, pero más que nada ve por objetivos de decir, ah, si me cambio ese otro lenguaje voy a ganar el doble, entonces déjame ir viendo esos otros, porque hay muchos trabajos de eso, es más posible, es más fácil que me contraten esos lenguajes. Tenemos ahorita un problema en la programación que nos estamos etiquetando, nos etiquetamos, yo soy programador de C#, yo soy programador JavaScript, pero sabes qué es lo peor, que nos estamos etiquetando ya por frameworks. Ya estamos, yo soy programador Angular, yo soy programador React, o sea, ya no soy programador frontend, yo soy un programador Angular. Y eso es peor porque es más complejo tanto para el reclutador y para el programador encontrar trabajo, porque estás dividiendo bastante las cosas cuando los conceptos son los mismos. O trabajas en Angular y React, muchas cosas se van a, se van a estar igual, el concepto existe, no es frontend al final de cuentas. A lo mejor tienes que hacer ciertas cosas de distinta manera, pero eso es lo que yo veo, que el gran problema hoy en día en la programación es que nos estamos etiquetando cada vez con especialidades más pequeñas Y de repente pues buscas un programador de Angular y resulta que el React puede trabajar en Angular, pero tú no lo aceptaste porque trabaja en React. Al final de cuentas, cuando debiste haberlo entrevistado con los conceptos de frontend y no de Angular, ¿no? Y aquí pasa lo mismo con C#. Si tú vas a aprender C# para backend, aprende los conceptos: qué es HTTP, qué es una solicitud, qué es segundo plano, qué es un stored procedure. O sea, tú todos esos conceptos, si te pasas después de C# a Java van a ser los mismos. O sea, vas a utilizar las mismas cosas escritas diferentemente, que la concurrencia, que es paralelismo, pero va a ser lo mismo. Por eso métanse a aprender C#, pero siempre con la noción de aprender los conceptos y saber que esos conceptos se van a replicar en otro lenguaje que sea de backend. No pasa nada si te cambias. Es algo de lo que estoy luchando bastante, y como divulgador, de romper ese cristal de de que se creó de mentira, de decir un programador de Java con 10 años de experiencia no puede programar en C#. Claro que puede programar en C#. Las de 2 semanas y ya aprende el lenguaje, y todos los conceptos que tiene de 10 años los va a replicar, no va a ser tan complejo. Pero eso está muchas veces, obviamente hay lenguajes más exóticos que es más difícil de repente pasarte. Obviamente es pasarte de C# a Elixir, cosas que tú usas, Erlang, no es tan fácil. Pero sí se puede, y sobre todo si vienes ya con nociones de programación funcional y concurrencia. Pero lo que voy es de que al final de cuentas los programadores antes no se buscaba como programador etiquetado, se buscaba yo necesito un programador y ya tú llegabas y ya te acoplabas al lenguaje que fuera, o sea, tal cual así, así era. Ahora se limita bastante por eso y por eso hay muchas personas que no encuentran trabajo. Pero sí, al final de cuentas aprendan conceptos, esa es la base, la programación.

Es curioso que cada vez que se va avanzando en informática se va creando eso de lo que tú dices, pequeñas islas que al final son todas muy parecidas, o si no iguales, porque es como tú dices, Angular, Vue, React, es que al final todo sirve para lo mismo aunque lo hagan de forma un poco diferente. Estoy completamente seguro de que algún programador de React con un día que eche un vistazo a Vue, ya lo puede poner en su currículum.

Y eso, y eso es todo un tema de que se ha creado un dogma de programadores como el fútbol, no, este programador es de este equipo y no puede pasar al otro equipo. Claro que puede, o sea, darle el tiempo y se pasa, y no necesita tanto tiempo. Y a lo mejor te vas a ahorrar más tiempo tú contratar un programador de 10 años de experiencia en frontend o en backend de cualquier lenguaje que sea, a que estés tú buscando un lenguaje a fuerza, un programador de un lenguaje exótico que utilizaste tú. Por ejemplo, Groovy on Rails, Groovy on Rails, que era una cosa que imitaba Ruby on Rails pero creo que en Java, o no sé, una cosa rara. Y hubo una, una, o sea, estoy hablando como un ejemplo de cosas extrañas que se utilizaron y ya no hay programadores de eso porque es difícil. Pero créeme que un programador de Java se puede acoplar. A lo que voy es de eso, se está creando se creó un cristal, porque es un cristal. Simplemente estás bloqueando que el proceso sea más lento, más burocrático, más— al final no está llevando el objetivo que quieres, encontrar un programador y el programador un trabajo. Entonces hay que romper esos dogmas.

Bueno, pues nos quedamos con la esencia de que hay que ir a por los principios, los conceptos y la base, y que en cualquier momento te puedes cambiar de lenguaje de programación. No sabes si al final puede estar programando en C#, en Java, en Elixir, en cualquier otro lenguaje de programación.

Yo conozco gente que de mi época que trabajó conmigo en el gobierno, que trabajamos con PHP, y dos personas que se pasaron con C#, se pasaron a JavaScript, y la última vez que supe de un amigo está trabajando con Delphi. O sea, con cosas que se cree que ni existen, y está trabajando con Delphi, le pagan bastante bien porque son lenguajes Que es lo que voy, búscate un programador Delphi, no lo vas a encontrar tan fácil. Búscate un programador y acopla lo que traje con Delphi, va a ser más fácil. Entonces ese es el punto.

Bueno, pues ya llevamos más de una hora, así que yo creo que es hora de darle el cierre. Ha sido un placer estar contigo aquí hablando de todos estos temas, muy interesantes, y nos han dejado mucho aprendizaje. Si quieres decir algo para terminar.

Solamente lo que quiero decir es que es un mensaje sobre todo que para muchos programadores que están empezando, que están abrumados porque creen que, a lo que voy, se aprende conceptos, pero he dicho conceptos fundamentales, conceptos fundamentales. La curva de aprendizaje parece al principio va a ser, parece que es grande, pero es como toda carrera. Métete a licenciatura de abogado, métete a arquitecto, todas son carreras que tienes que aprender mucho al principio. No se abrumen porque la curva de aprendizaje parezca larga al principio, después la curva se va aligerando. Después la curva, tú solamente ya vas aprendiendo lo que necesitas en el momento. Así que lo más difícil es el primer trabajo, y sobre todo ese es un mensaje motivador. Lo más difícil, el primer trabajo. Después va a ser más fácil porque tú ya vas a estar empapado de qué es trabajar como programador. Te vas a dar cuenta que muchas de las cosas tienes que seguir aprendiendo, pero ya no es tan, tanto como se cree. Así que no se abrumen. Al final de cuentas, yo tengo 20 años trabajando y a veces se abruman. Es que tú hablas de tantas cosas. Tengo 20 años, o sea, 20 años trabajando, y muchas de las cosas que aprendí también las utilizo. O sea, es así, también pasa. Hay que aprender a reemplazar conocimientos con nuevos conocimientos, pero eso te va a ir dando ya una vez que tengas tu primer trabajo. La necesidad del requerimiento te lo va a ir dando. Necesito hacer esto, solamente aprende sobre eso y tu cerebro enfócalo sobre eso. Y todo eso es experiencia que vas a ir adquiriendo, que cuando busques otro trabajo, todos esos conceptos y experiencias te van a servir. Así que no se abrumen porque se vean tantos conceptos. Los conceptos fundamentales no son tantos, pero es una base que se va a repetir. Así que esa base, si la aprendes bien, se va a repetir en los trabajos, se va a repetir en la mayoría de lenguajes de programación. Así que no vas a tener que volver a reaprender otra vez esos conceptos. Así que enfóquense en los conceptos, no se abrumen. La curva de aprendizaje se pone más ligera conforme vayan avanzando. Y no crean que la programación Es una vida, es una profesión. Descansen, al final de cuentas tomen su tiempo libre para descansar. No, no se sientan el Mr. Robot, o sea, hay que descansar y vivir la vida más que nada.

Pues vamos, gran aprendizaje, grandes conceptos, aunque no de programación, pero también son necesarios. Bueno, me quedo también con la cosa de poner en la caja de descripción, que no sé si estará muy visible o no, los canales de los podcast, pero agrego tu canal de YouTube de H de León e incluso el libro de C#, por si alguien se anima a comenzar teniéndote como tutor. Y muchas gracias por haberte pasado y haber compartido con nosotros esta tarde.

No, pues muchas gracias a ti por la invitación. Ya sabes, cuando gustes me paso de nuevo.

Bueno, pues este ha sido otro capítulo de Codeadores. Ya sabéis, nos vemos cada martes en otro programa, otra cita con otras personas.