NoCode, LowCode y LowLevelCode con Mariano Guerra

Bienvenidos otra semana más a Codeadores. Esta semana, en lugar de centrarnos en un lenguaje específico, hablando con Mariano Guerra, que es quien nos acompaña hoy. Buenas, Mariano.

Buenos días, ¿qué tal?

Pues estuvimos hablando sobre el tema de no-code, low-code, incluso low-level code, y que ya después explicaremos un poco. Y me llamó mucho la atención hablar de algo que no es programación per se, pero que sí está muy ligada a la programación por que permite hacer cosas sin expresarlo con código específicamente. Entonces, la primera pregunta que siempre me gusta hacer es acerca de los orígenes de la persona que viene aquí a hablar. Así que te voy a hacer, o sea, te voy a dar pie para que te presentes un poco, pero además si puedes introducir el cómo te llamó la atención la informática, cuál fue tu introducción o qué te hizo clic para decir quiero dedicarme a esto.

Sí, soy Mariano, originalmente de Córdoba, Argentina, pero hace bastantes años que vivo en Stuttgart, Alemania. Y la programación creo que es al menos una historia que se repite bastante en nuestra generación, que empieza un poco por los videojuegos. Cuando era chico tuve la suerte de tener una computadora desde chico, desde los 7 años más o menos. Inicialmente, como casi todos, lo usábamos para jugar juegos nada más. No nos interesaba mucho más de qué comandos escriben DOS para que arranquen los juegos que tengo. Pero también me gustaba dibujar, entonces pensaba, un pensamiento decía quería quizás hacer un cómic, pero decía, pero más divertido que un cómic es un videojuego, porque un videojuego es como un cómic interactivo. Entonces me quedaba la idea esa de cómo serán los juegos. Y después con los años me di cuenta que podría haber empezado a programar mucho antes porque jugaba unos juegos en una cosa que yo no sabía qué era, que era QBasic. Yo escribía QBasic, elegía una cosa, ponía Run y aparecía un juego. Y nunca sabía que lo que yo apretaba Run antes del juego, el texto ese que estaba escrito, era el código del juego. Si alguien me hubiera dicho el juego es eso que está ahí, quizá hubiera empezado como 10 años antes. Pero nunca conocí ningún programador ni nada, así que no no tenía la más pálida idea cómo se hacían esas cosas. Y en la adolescencia apareció una noticia en la televisión de un chico de mi edad que salía en las noticias porque tenía una página web. Y yo digo, uno sale en las noticias por tener una página web, ¿cuán difícil puede ser? Y esto va a delatar mi edad, y me fui a un cibercafé, que en esa época era muy caro, y me bajé en un par de disquetes tutoriales de cómo hacer páginas web. Entonces volví a mi casa y abrí el Notepad e Internet Explorer y empecé a escribir HTML. Y así empecé. Y por unos años hacía mi página personal, hacía páginas de unos proyectos que tenía con unas amigas, pero no sabía ni siquiera si eso se considera programar o no, o si hacer juegos es algo parecido o no. De vez en cuando copiaba con ver código fuente, copiaba un poco de algo que hacía que se animara algo, que en ese momento era JavaScript, que ni sabía yo, pero funcionaba. Y después mi hermano más grande entra a estudiar ingeniería y en el primer semestre tiene una clase de programación y vuelve a mi casa y me da un libro y me dice, a vos te gustan las computadoras, lee esto y explícamelo. Entonces ese libro que me da era un libro de programación en C++ para ingenieros, así que lo leí y lo ayudé a hacer los ejercicios del semestre, pero después dejé de hacer O sea, lo dejé como, ah, mire qué curioso. Y después de unos años nos mudamos y yo vivía muy lejos de mis amigos, y entonces tenía mucho tiempo libre sin mucho más que la computadora, que no tenía conexión a internet en esa época. Entonces, medio curiosidad, otra vez delatando mi edad, ya la estoy delatando muchas veces, mi madre se compró uno de los primeros Nokia, los teléfonos pero los grandes que parecían ladrillos, y tenía un juego adentro que era el de la viborita. Y otra vez me pregunté cómo se hacen estos juegos de la viborita, como cualquier juego, pero este de la viborita me parecía lo suficientemente fácil como para decir esto que yo sé de C++ probablemente pueda hacer un juego como la viborita. Así que me fui a otro cibercafé, me bajé un compilador de C y empecé a intentar en mi casa hacer un juego de la viborita sin conocer a nadie que supiera programar, por lo tanto me tomó bastante tiempo. Y bueno, y ahí entonces ya estaba por tener que terminar el secundario y iba a estudiar licenciatura en ciencias económicas, pero mi papá me dijo, hay muchos economistas en el mundo, ¿por qué no estudias algo relacionado con las computadoras? Entonces fui a la ciudad universitaria y pregunté qué carreras había, y resulta que fui a una facultad de ingeniería y me anoté ahí y terminé siendo programador. Pero todo muy accidental y curiosidad más que todo de ver y decir, ah, ¿cómo se hará? Y libros que me cayeron, porque si me cae un libro de Pascal o un libro de Visual Basic, lo que fuera, iba a terminar programando en eso. Eso, digamos, es algo que que un poco envidio de las generaciones más nuevas es la mayor facilidad del acceso a la información. O sea, mi aprendizaje se basó en las cosas a las que tenía acceso, o digamos ver algo y decir, ok, puedo ir al cibercafé y buscar en Altavista en esa época cómo se hace una página web. Pero si nadie me decía que HTML era eso, o que los juegos se pueden programar en C++, o que C++ es un lenguaje de programación, ni me enteraba. Fue medio caótico y medio aleatorio, pero bueno, a que termine.

Yo te conocí sobre todo en la parte del mundo de Erlang, pero lo que más me llama la atención es de la página web que tienes cuando empezaste a publicar artículos acerca de no-code, low-code principalmente. ¿Cuál es la diferencia entre estos dos términos? ¿Hay alguna diferencia o son sinónimos?

Se encuentran un poco en el medio. La idea de no-code es literalmente que es un error que cometió NoSQL, también es definirse como lo que no es, lo que uno no es, o como contraposición a otra cosa, pero lo describe bastante bien. La idea de no-code es poder lograr cierto tipo de actividades que normalmente las puede hacer un programador escribiendo código, pero sin escribir código. Y obviamente uno dice, bueno, sin escribir código, pero escribir haciendo qué sin escribir código. Lo que normalmente se termina haciendo es algún tipo de entorno visual interactivo en donde uno describe algo, y ese algo depende, depende realmente cómo es definido con lo que no es. Lo que puede ser es un montón de cosas, entonces deja abierto mucho la cuestión del diseño, pero normalmente lo que termina haciendo es un ambiente para desarrollar soluciones a problemas en un vertical bastante específico, en un nicho bastante específico. Entonces podemos crear una herramienta no-code para validación de datos, una herramienta no-code para visualización de datos, una herramienta no-code para, no sé, prototipar aplicaciones móviles. Entonces lo que uno hace es restringe muchísimo el dominio a un tema en particular y trata de diseñar algún entorno interactivo y visual en el cual uno pueda describir la solución con algún tipo de componentes visuales y el runtime genera un programa, ejecuta e interpreta lo que uno describió. Lo que se caracteriza en el mundo no-code es que cada herramienta tiende a ser muy específica a un dominio porque diseñar un lenguaje visual no es fácil y también la cuestión de que si uno trata de hacer una herramienta a propósito general visual es muy difícil y no solo es difícil de crear y desarrollar sino que es difícil de explicar, porque al fin y al cabo si es una herramienta de propósito general estamos de cierta manera también programando. Entonces terminan siendo muy de nicho y digamos el pro es que son fáciles de usar y como son de nicho muy rápidamente logramos una solución al problema que estamos tratando de solucionar, siempre y cuando la herramienta nos permita solucionar el problema que nosotros tenemos. El problema que tienen las herramientas no-code es que o se puede o no se puede, o sea hay un subset de cosas que soluciona y si no se puede, no se puede normalmente. Ese es más o menos el no-code. Y low-code lo que es, es un enfoque distinto, que es esta idea, nunca me acuerdo en cuál libro de Fred Brooks, la idea de la complejidad accidental y la complejidad esencial. La idea es que cuando nosotros estamos solucionando un problema programando tenemos dos tipos de complejidades: la complejidad esencial, que es el problema que estamos solucionando tiene un nivel de complejidad que no lo podemos esquivar porque que por eso es un problema. Y en la complejidad accidental es todo lo otro que tenemos que hacer por las herramientas que estamos usando y por las limitaciones de la tecnología para solucionar el problema. Entonces, digamos, crear un proyecto en Python es complejidad accidental. O sea, el problema de, no sé, de hacer un balance contable es la complejidad esencial del problema. Tenemos que hacer el balance. Tenemos que gestionar dinero, tenemos que hacer un balance, tiene que tener sentido, tiene que seguir las reglas de la contabilidad. Pero configurar en nuestro editor de texto o crear un proyecto en Python o crear una API REST no es esencial al problema de la contabilidad. Entonces las herramientas low-code lo que intentan hacer es decir, ok, ¿por qué no tratamos de ya sea eliminar o abstraer toda la complejidad accidental y que el el usuario de nuestra plataforma se dedique solamente a escribir el código que es específico al problema que estamos resolviendo. Y la forma más fácil de ilustrar esto es Ruby on Rails. Ruby on Rails, si bien uno lo puede considerar un framework y que es código, código normal, digamos no-code y low-code son dos puntos en el espectro donde tenemos, imaginemos a la izquierda programar en assembler o en binario, luego programa en lenguaje de bajo nivel, lenguaje de medio nivel, lenguaje de alto nivel, low-code, no-code. Es como un espectro de cómo podemos solucionar un problema. Digamos, Ruby on Rails es de la programación en general lo más cercano a lo que uno se puede imaginar con low-code. ¿Por qué? Porque Ruby on Rails dice, nosotros vamos a hacer un framework que vamos a servir solamente si querés programar en Ruby y si querés escribir aplicaciones web que son básicamente alta, baja y modificación. Si ese es el tipo de problema general que vos estás tratando de solucionar y vos me describís el esquema de la base de datos relacional, porque esperamos que vos tengas un frontend web, un backend REST y que tenga una base de datos relacional. Si vos me describís el esquema de tu base de datos relacional, un montón de código lo vamos a escribir nosotros, o lo vamos a generar nosotros, o lo vamos a traer. Entonces vos te dedicás a describir la complejidad esencial del problema, que es cuál es el esquema de mi base de datos, cuáles son las reglas, los... ¿cómo se dice? Las reglas que no se puedan romper, tipo cuestiones de relaciones, validación de campos, permisos, lo que fuera. Y el framework en sí nos abstrae de toda esta complejidad accidental que existe en cualquier tipo de software que nosotros queramos escribir que tenga un frontend web, un backend REST y una base de datos relacional. Local va un poco más allá y dice, bueno, lo que podemos hacer es no te vamos a generar con una línea de comando un montón de archivos en tu directorio y vos tenés que escribir un comando para iniciar un server, después tenés que escribir migraciones, lo que fuera. Nosotros te vamos a crear una interfaz de usuario en donde te ponemos un mini editor de código y vos solamente escribís el código de los handlers, por ejemplo. El resto te lo gestiona la plataforma. Entonces trata de sacar el acto de programar de directorios con ficheros y una interfaz, una IDE o un editor de texto, a un entorno un poco más visual, más específico y más restringido en el cual tenemos que saber menos cosas y podemos cometer menos errores. Pero de nuevo la contra de eso es, digamos, la comparación, porque por ejemplo hay muchas plataformas low-code que compiten un poco con Ruby on Rails, por ejemplo. Pero imaginemos que de pronto necesitamos hacer un tipo de procesamiento de imágenes. El usuario puede subir una imagen y necesitamos achicarla a cierto tamaño. En Ruby on Rails lo podemos hacer porque detrás de Ruby on Rails está Ruby, un lenguaje de propósito general que tiene librerías. Podemos instalar una librería y bueno, lo resolvemos. Pero si estamos resolviendo el mismo problema en una plataforma low-code, por ejemplo Raytool, y la plataforma no nos brinda esa funcionalidad, ahí se acabó. Si bien es quizás, digamos, la complejidad— siempre tengo que pensar cuál es la que estoy diciendo— esencial del problema la estamos podemos resolver en JavaScript o en Python o en Ruby escribiéndolo en alguna caja de texto, la funcionalidad que nos expone la plataforma es limitada. No podemos instalar cualquier paquete o correr una línea de comando o hacer una solicitud a otra API. Nos restringe más y es como un balance que es el ida y vuelta constante de estas ideas de no-code y de low-code y de programación de alto nivel. Al hacer más simple el desarrollo para un caso en particular, muchas veces lo que uno termina haciendo es eliminando la capacidad de resolver problemas que estén por fuera de eso que uno está tratando. Entonces, al principio uno siente que avanzó muy rápido y que soluciona problemas muy rápido, pero de pronto necesita algo que la plataforma no consideró y ahora ya no se puede. Y ese es un problema muy común de no-code y low-code. Los usuarios más felices de ese tipo de plataformas son los que recién empiezan a usarla y sienten ese progreso rápido del inicio donde todo, comparado con lo anterior, es impresionante. Pero una vez que quieren hacer algo que va por fuera, que no fue considerado por la plataforma, empiezan a encontrar las limitaciones. Y los usuarios que menos les gusta eso normalmente son los que que no se alinean al 100% con el problema que soluciona la plataforma, o tienen uno o dos, o sea, o funciona perfecto para todo, pero tienen uno o dos casos puntuales en los cuales necesitan hacer algo por fuera de lo que la plataforma provee. Y muchas veces esas plataformas nos dejan sin ninguna opción. Obviamente, yo siendo una persona que está interesada en esto y que ha creado producto en el espacio, Considero que siempre hay que tener esa consideración y tener lo que se llama válvulas de escape o escape hatches en inglés, que es dejar en la plataforma puntos en los cuales uno puede decir, OK, si la plataforma no me permite decir esto, al menos déjame, no sé, hacer un request HTTP a un servicio externo. Entonces implemento ese caso en particular que vos nunca vas a soportar en otro lado, pero vos déjame llamar allá porque si no, o sea, No me sirve tener una solución que solucione el 98% de lo que necesito, pero el 2% restante no lo puedo solucionar porque necesito la solución completa. Entonces es siempre un balance constante de mientras más fácil y más rápido uno es productivo en lo que se llama el happy path, el camino feliz, tiende a ser en contra de que cuando uno se desvía un poco del camino feliz, la herramienta no nos provee ningún tipo de funcionalidad para solucionar ese tipo de problemas. Y es un balance constante de diseño y encontrar el punto perfecto y qué problema uno está tratando de solucionar.

Podríamos decir que dentro, o sea, por las definiciones que tú has dado, sistemas como Excel, por ejemplo, se podrían catalogar como no-code.

Sí, Excel es no-code Pero tiene la cuestión particular que lo hace muy interesante, que es, es muy de nicho. Excel es si tenés números normalmente, y es muy visual y muy interactivo. Y también tiene esta cuestión de live, vivo, que cambiamos y siempre vemos constantemente, se actualiza constantemente todo a medida que vamos haciendo los cambios. Entonces muy interactivo, tiene un un feedback loop muy chiquito y muy adictivo de cierta manera. Pero las fórmulas no solo son texto sino que es una sintaxis muy fea, perdón si alguien considera que la sintaxis de las fórmulas de Excel son lindas, pero también Excel no provee mucha funcionalidad para que editar fórmulas sea una experiencia muy agradable. Tenemos ahí un input de una línea que tenemos que cerrar los paréntesis y contarlo, no tenemos syntax highlighting, no tenemos digamos un linter o nada. Yo creo que quizás lo hacen a propósito para para que uno considere siempre, muchas veces cuando uno está diseñando una solución, si uno tiene que proveer una funcionalidad pero no quiere promover su uso, la hace de cierta manera un poco incómoda, un poco molesta. Entonces uno tiene que pensar dos veces, decir, esta fórmula se está descontrolando, quizás tengo que frenar y pensar un poco y ver si no hay otra funcionalidad para solucionar el mismo problema, o quizás simplifico la fórmula, o quizás Python, quizás Excel ya no me alcanza y tengo que ir a otra cosa como Python. Yo creo que va un poquito por ahí, porque Excel tiene sus años, deben haber recibido el feedback de que editar fórmulas de Excel no es una experiencia muy agradable. Tiene esa cosa particular de que es muy no-code, excepto que las fórmulas son una experiencia muy, o sea, que un programador se puede ver reflejado. Es sintaxis con paréntesis, balance de paréntesis, errores de sintaxis, variables, strings. Sí, tiene esa ambivalencia Excel que es muy Interesante. De hecho, hay un libro que les recomiendo si les interesa mucho esto, es de Bonnie Nardi, que es una investigadora que se puso a investigar un poco de cómo los usuarios finales usan estas herramientas que tratan de proveerle a los usuarios finales las capacidades que normalmente son solo accesibles a programadores. A Small Matter of Programming, creo que se llama en inglés. Pequeña no sé qué de programación. Es difícil de conseguir el libro en físico, pero quizás digital es un poco más fácil. Pero hay mucha gente que ha investigado, digamos, cómo la gente normal usa herramientas como Excel y cosas así.

Otros lenguajes que caen siempre dentro de la rama visual, pero yo no sabría catalogar exactamente, por ejemplo, lenguajes como Scratch, que se construyen con bloques visuales. Pero aún así da la sensación de seguir siendo código. ¿Ese sería low-code, no-code, o seguiría un lenguaje normal?

Sí, Scratch es interesante porque ahí está la— hay dos cuestiones. Una razón por la que lo consideraría no-code es porque no tiene sintaxis, o de cierta manera la forma en la que Scratch está diseñado no nos permite cometer errores de sintaxis. Un programa en Scratch siempre es sintácticamente válido. Si bien semánticamente puede no tener sentido, siempre va a ejecutarse, quizá va a generar un error, lo que fuera, pero elimina ese, ese primer paso de frustración de cualquier persona aprendiendo a programar o tratando de usar una herramienta para solucionar un problema, que es balancear los paréntesis, poner los puntos y comas, cerrar las comillas, o cometí un error de sintaxis y el error de sintaxis no tiene sentido, no encuentro dónde está porque no tengo la experiencia de programar y de solucionar errores de sintaxis. Entonces lo que hace interesante a Scratch es elimina la posibilidad de cometer errores de sintaxis. Por ese lado lo consideraría no-code. Por el lado de que no lo considero tan no-code es porque muchas veces se asocia no-code con herramientas más declarativas. De cierta manera la herramienta no-code es un lenguaje de dominio específico que describe la solución en términos del problema y de una forma más declarativa, más estilo SQL. Que Scratch. Scratch es muy secuencial, muy procedimental. Digamos, si uno lee un programa de Scratch lo puede traducir línea a línea a Python. Es muy— es como si agarráramos un lenguaje de programación tipo Python o de la familia de ALGOL y por cada elemento de sintaxis creáramos un bloque. Entonces lo que hace Scratch es eliminar esa potencialidad de crear errores de sintaxis, pero no es muy declarativa, por decirlo así. Es muy parecido al lenguaje de programación. Y el problema es, si uno lee la investigación con respecto a Scratch, se encuentra en un punto también muy curioso porque se usa mucho para enseñar programación, pero el problema que tiene es que muchas veces los chicos lo rechazan porque piensan que de cierta manera lo están engañando. En el sentido de decir, yo he visto gente programar y los programadores no programan así. Esto vos me estás dando como una especie de juguete porque tiene todos colores y son todos bloquecitos. Yo quiero programar como programan los programadores en serio, quiero una pantalla negra y con las letras de colores raros, no quiero programar así. Entonces cae en ese punto en el medio en el que está muy cerca de ser programación, es casi programar en Python pero sin sintaxis, pero muchas veces la gente que lo está aprendiendo siente que los están engañando. Que les están dando algo de juguete y no algo que es real. Cuando en realidad los algoritmos que uno escribe en Scratch son casi uno a uno linealmente lo que uno escribiría en un lenguaje de alto nivel. Pero tiene esas dos contras, digamos, el de no se lo toman en serio porque no parece programación en serio cuando en realidad está muy cerca. Y elimina uno de los problemas principales de enseñar a programar que es aprender a programar sin cometer errores de sintaxis o si cometemos un error de sintaxis, encontrarlo y solucionarlo. Pero por el otro lado, lo que también soluciona mucho todas estas herramientas no-code, pero también Scratch, es el problema de la página en blanco. Si yo le digo a una persona te voy a enseñar a programar en Python y le doy un editor de texto vacío, esa persona no sabe qué es posible, qué hay disponible en el lenguaje Python, porque tengo un editor en blanco y digamos la sintaxis de Python la tengo que tener en la cabeza. O las librerías las tengo que tener en bibliotecas, las tengo que tener en la cabeza. En cambio, lo que está bueno del lenguaje no-code o algo como Scratch es que tengo un menú a la izquierda de todo lo que se puede hacer. Entonces puedo abrir ahí y decir, ah, mira, se puede imprimir, se puede reproducir un sonido, ah, mira, puedo mover a la derecha. Entonces puedo ver qué es posible. En los lenguajes de programación, digamos, como los conocemos nosotros, hay un libro o una documentación, una referencia en algún lado que dice qué es posible. Lo tenemos que poner en nuestra cabeza y después saber pensar qué problema, cómo queremos resolver el problema, y empezar a escribir lo que queremos. Las herramientas no-code son más de demostrarte que esto es posible, lo cual hace más fácil explorar, jugar, probar, o encontrar algo que uno no sabe que está disponible. Porque puede ser que uno programa en un lenguaje por 2 años y decida, mira, no sabía que se podía hacer esto porque no lo vi nunca, y cómo voy a saber. En cambio, los entornos no-code es más interesante que uno pueda abrir un menú y ver qué es lo que se puede hacer.

Y teniendo en cuenta la perspectiva histórica, entre no-code y low-code, ¿sabes cuál fue primero y cuándo surgieron cada uno?

Estás ejercitando mi memoria, pero de hecho, si me apuras, diría que que no code fue primero. Hay un proyecto que se llama Pygmalion, que creo que de 1970 y poco, que es un intento de hacer programación visual. Después está Ink, un proyecto de— después voy a pasarte los links porque mi memoria es muy mala con los nombres, pero que es una tesis de doctorado en donde una persona trata de hacer un entorno para ingenieros mecánicos para interactivamente crear diagramas de piezas, pero con lo que fue, se consideró el primer sistema orientado a objetos. Y eran dos lenguajes visuales de principios de los 70. Low-code, los primeros que consideraría low-code, bueno, que son de la misma época más o menos, para esa época se consideran low-code, hoy en día no. Lisp del final de los 70 Porque en comparación con los lenguajes que había en ese momento, la diferencia entre Lisp, un lenguaje de altísimo nivel aún hoy, y lo que había a fines de los 60 era casi no-code. Eso después, a mediados de los 70, tenemos Smalltalk, que también yo lo consideraría aún hoy low-code porque uno programa en un entorno visual en donde uno escribe en pequeñas cajitas métodos, pero el ambiente está constantemente vivo y uno puede inspeccionar y lo que fuera. Y el tercero que consideraría low-code, que también es de los 70, es SQL. O hay un par de lenguajes antes de SQL que también lo podríamos considerar. Que lo que tiene interesante SQL es que primero que es declarativo, o sea, uno no describe la solución sino que describe qué es lo que uno quiere. Y el motor de la base de datos es el que traduce la descripción de lo que uno quiere a cómo se va a buscar en la base de datos. Pero también porque fue creado originalmente para que las personas, entre comillas, de negocio puedan hacer las queries por su cuenta, que no tengan que ir a un programador. No terminó sucediendo. Otro que inicialmente fue diseñado con esa intención, que fue diseñado con la intención de que lo usaran personas de negocio ya sea para ellos escribir el código o para sentarse con un programador y poder leer el código que el programador estaba escribiendo, es COBOL, que hoy no lo consideraríamos low-code bajo ningún concepto, pero que la intención estaba ahí. Es decir, siempre, digamos, es una intención que está constantemente o se renueva con nuevas oleadas de gente tratando de encarar y solucionar el problema, que es cómo podemos hacer como base que lo que llamamos el lado del negocio, los que no programan pero los que tienen el problema o los que entienden más el problema que nosotros, puedan al menos leer el código y entenderlo. Quizás no escribirlo, quizá cambiarlo o quizá encontrar un error. El siguiente paso es qué pasa si pueden escribirlo un poco, aunque sea para problemas simples. Y el tercero es qué pasa si pueden simplemente escribirlo. Pero Es un poco como la inteligencia artificial. La definición de programación se mueve constantemente, pero lo que se mantiene constante es: hay un problema y alguien le describe a una computadora cómo se soluciona una generalización de ese problema. O sea, el problema en el caso general para una cantidad de argumentos. Entonces quizás si hoy viene alguien del fin de los 60 y me ve programar en Python, va a decir que yo soy un programador low-code o que no soy un programador. Realmente esa discusión no me parece— a mí me gusta solucionar problemas. Si se llama programación o no se llama programación no me inquieta mucho.

Estábamos hablando antes también sobre las comunidades no-code, que según me comentaste había diferentes islas o diferentes comunidades que estaban haciendo lo mismo pero no se ponían de acuerdo porque utilizaban términos y cosas diferentes. Hay mucha aversión entre comunidades de no-code e incluso programadores entre estas comunidades de no-code.

Pasa algo muy curioso que refleja mucho lo que termina pasando en el mundo de la programación, que es en el mundo de programación tener gente que dice yo soy un programador Python o yo soy un ingeniero React.js o yo soy un programador de Ruby. No sé, me parece que es innecesaria la restricción. Obviamente uno puede decir como me interesa esto o estoy buscando gente que tenga el mismo interés que yo, pero encasillarse en un lenguaje como yo programo en este lenguaje y no en programa en general, curiosamente termina pasando lo mismo en las comunidades no-code. Tenés distintas herramientas como Airtable o Webflow Hay miles, no sé si miles, pero cientos ahora. Y terminas encontrando gente que dice, ah, yo soy un, de hecho dicen programador no-code, y dicen las herramientas que usan. Y de cierta manera tiene sentido. ¿Por qué? Porque como cada una de estas herramientas es un nicho, por ejemplo Airtable es como una especie de Excel++, es un nivel más arriba de Excel. Para algunas cosas y para otras no, en el sentido que Excel en realidad es una grilla de valores y digamos uno puede entre comillas poner la restricción a qué puede ir en las celdas, pero es una restricción que a Excel le importa bastante poco. O sea, uno puede crear una tabla entre comillas en Excel, pero para Excel es una grilla de celdas, no es una tabla. Entonces si uno hace ordenar una columna no nos va a ordenar las otras. No nos va a reordenar las filas porque Excel es una grilla de celdas, no es una tabla. Y también Excel es muy plano en el sentido de que casi todo es un string al fin del día. Entonces lo que Airtable hizo, que es un poco la actitud no-code de esta, es decir, hay un montón de gente que usa Excel para tener tablas y quiere poder ordenar por una columna o por múltiples columnas, pero también quiere poder restringir y decir en esta columna solamente puede haber 3 valores, no sé, prioridad 1, prioridad 2 y prioridad 3, y quiero que prioridad 1 sea tal color y prioridad 2 sea tal color y quiero que se ordenen así y quiero que si uno cliquea en un valor prioridad 2 que se filtre solamente la prioridad 2, que es algo que mucha gente termina haciendo mil veces en Excel. Entonces en la Vertable dijeron ¿por qué no hacemos, restringimos Excel a esto? No es más grillas de celdas, es tablas. Y no es más string, sino que te permitimos crear tus propias enumeraciones y valores de más alto nivel, colores, URLs, rating de 0 a 5, lo que fuera. Lo cual hace mucho más fácil solucionar el problema que uno tiene, si el problema que uno tiene tiene la forma de lo que Airtable permite. Entonces hay muchos programadores Airtable. Y después tenemos herramientas como Webflow que nos permiten hacer páginas web interactivas. Y lo que termina pasando también es que Cada una de esas herramientas termina creando su propio vocabulario. A esto lo llamamos así y a eso lo llamamos así. Y a las condiciones no les llaman condiciones, les llaman rules. Entonces cuando uno se mete más en estas herramientas no-code termina aprendiendo un lenguaje de dominio de la herramienta que no se traslada a las otras herramientas. Si uno sabe programar en Python y tiene que aprender JavaScript o Ruby, casi todo se transfiere porque todos vienen del mundo mutable, orientado a objetos, algo... Estilo con alguna influencia de Lisp o Smalltalk. Entonces hay un montón de contexto compartido entre las comunidades. Estas herramientas no-code crean un vocabulario, un set de conceptos con sus nombres propios que encima son específicos a un dominio y es muy difícil saltar de una herramienta a la otra porque no tienen ni siquiera ninguna motivación de ponerse de acuerdo de cómo le llamamos a una condición. Por ejemplo, o cómo le llamamos a un booleano, porque obviamente no le van a llamar booleano porque no es un buen nombre para ponerle a esas cosas. Entonces le ponen, no sé, logic value le pone uno, y el otro le pone, no sé, truth value, o no sé, condition value. Y cuando uno aprende a usar una herramienta, casi nada de lo que uno aprende se transfiere a la otra herramienta porque cada una está muy específica en un nicho. Y entonces termina pasando eso, que terminan aprendiendo mucho a usar las herramientas y no mucho a pensar, digamos, computacionalmente, por decirlo así. Y no se transfiere mucho el conocimiento de una herramienta a la otra.

Entonces, saliendo un poco del no-code y nos metemos ahora en low-code, habías puesto como ejemplo Ruby on Rails, supongo porque hay que escribir muy poco código y ya el framework te da mucho hecho. Si Ruby on Rails ha evolucionado hasta llegar a ser prácticamente un low-code, ¿Ese es el destino que tienen la mayoría de frameworks, de proporcionar a cada programador para desarrollar cierto tipo de soluciones una herramienta que al final sea como low-code?

Digamos, es una decisión que tiene que tomar la comunidad de la herramienta, que es como decía, a medida que uno, si se esfuerza mucho en hacer mucho más fácil solucionar un problema general, una forma, la forma más normal de hacer que algo sea más fácil y más rápido y más simple, y que el framework o la herramienta haga más trabajo por nosotros, es restringir el dominio cada vez más. Entonces es un balance, no sé si es una regla universal, pero uno gana facilidad o simplicidad a medida que pierde generalidad. Y el punto no es ningún valor válido. Digamos, si alguien me dice tengo que crear una aplicación de altas bajas modificaciones para una clínica dental, sí, usa Ruby on Rails. De hecho, fíjate si no hay una herramienta low-code o no-code para clínicas dentales. Pero si uno me dice, mire, estoy explorando un montón de ideas o tengo que crear un software para una empresa que trabaja en 5 industrias distintas y tiene un montón de problemas, no usé una herramienta no-code porque te aseguro que no va a solucionar ni el 10% de los problemas que tienen. Una herramienta low-code tampoco. Así que ahí usan un lenguaje de propósito general. Quizás para ciertos problemas particulares podés usar un framework o una herramienta low-code, pero es como un balance. Mientras más— es la otra cuestión— mientras el problema que uno tiene más se parece al problema que mucha otra gente tiene, más probable es que haya una herramienta no-code o low-code que solucione el problema en particular que tenemos nosotros. Nosotros. Mientras más nos salimos de la norma, más probable es que nos vamos a, decimos en Argentina, nos va a dejar a patas. Que en algún momento la herramienta no nos va a permitir solucionar el 100% del problema que tenemos. Y lo peor que te puede pasar es que no te dé ninguna puerta de escape para decir, ok, no lo puedo solucionar en la plataforma, pero al menos me permitís solucionar este caso específico en otro lugar e integrarlo. A mí me gusta el balance de Ruby on Rails, me parece un caso de éxito. Otro caso de éxito en otro punto de ese continuo es Excel, que es muy curioso porque es eso, que el escape hatch de Excel es el lenguaje de fórmulas. Y es un trade-off muy curioso porque es una herramienta cuasi low-code, muy, muy, muy viva, muy interactiva, muy como que la gente la entiende rápido. Y la puerta de escape es un lenguaje que no es muy agradable, pero genera un balance en el cual he visto gente hacer cada cosa en Excel que es sorprendente y alarmante a la vez, las dos cosas. Uno se sorprende que alguien pueda hacer eso en Excel y uno se sorprende que alguien siga haciendo ese tipo de cosas en Excel cuando ya hace años que debería haberse pasado a otra herramienta. Pero ese también es un problema de las herramientas no-code, de las herramientas low-code en general, es que quizás inteligentemente no hay un plan de qué hago cuando esta herramienta me queda chica. No hay un, ok, evolucioné, o mi problema evolucionó, o ya estoy en otro nivel, o estoy teniendo otro tipo de problema más complejo, ¿a dónde voy? Y la solución siempre es, bueno, aprende Python, o aprende Java, o lo que fuera. Pero no hay como una secuencia de, ok, empiezo. Porque ahora está bueno eso de Excel, volviendo a Excel, que ahora se puede escribir Python en Excel de cierta forma. Entonces decís, ok, empiezo con Excel con la interfaz visual, Cuando necesito algo uso la fórmula, cuando se me empieza a quedar corto uso los macros, y cuando se me empieza a quedar más corto uso Python. Y ahí ya puedo empezar a usar Python para cosas chiquititas, pero ya puedo empezar a hablar con un data scientist. Entonces podemos empezar a hablar el mismo idioma, o le puedo empezar a decir por qué no empezar a agarrar estos macros que se están yendo de control y no me los migraba a Python. Hay como una un camino en el cual uno puede evolucionar. Y a medida que uno crece y el problema se vuelve más complejo, uno puede ir sacando de esta herramienta en torno al código low-code y poniéndolo en otro lugar, pero que no sea una reescritura de cero. Y muchas de estas herramientas yo creo que lo hacen a propósito porque no quieren que te vayas, no lo facilitan mucho.

Así, alguien tuviese o quisiera evolucionar su herramienta porque está dentro de un vertical específico y ha dicho, bueno, estamos creando una herramienta lo más fácil posible. Al final no es como un programa porque no se limita solo a formularios, sino que tiene que dar la posibilidad de extensión, ya sea con plugins o con código. ¿Cuáles serían las reglas para decir, para mantenerte dentro de low-code y que no sea una frustración para tu usuario? Tienes que cumplir esto. ¿Cuáles serían esas recomendaciones?

Uno tiene que buscar esas salidas de emergencia que ya medio se está estandarizando, que es, bueno, si nuestra herramienta no soluciona tu problema, acá podés hacer un request HTTP a algún servicio externo. O sea, la condición base es, si uno está explorando herramientas no-code o low-code, es siempre buscar que haya una puerta de escape para cuando la herramienta no solucione el problema que tenemos. Normalmente con que diga así se hace un request HTTP está bien porque eso significa que nos abre el mundo a la programación en general siempre y cuando podamos poner la información que queremos en el request y podamos, esta es la otra parte que es importante, es cómo maneja la respuesta, qué hace con la respuesta, puedo mostrar solamente texto o me restringe mucho a qué es lo que puede devolver o me permite, ¿por qué? Porque imaginemos que queremos hacer esta herramienta de de que uno suba una imagen y le quiero cambiar el formato y la quiero hacer de un tamaño determinado. Ok, puedo mandar la imagen, imaginemos que sí. Bueno, y ahora con la imagen nueva, ¿qué hago? ¿La devuelvo o le hago una llamada a una API externa? Digamos, no solo que nos dé la opción de salir al mundo de la computación general que asume el HTTP normalmente, ahora lo lo que se está explorando también con el modelo de componente de WebAssembly es herramientas como Shopify nos permiten, diríamos, subir nuestros componentes en WebAssembly y ellos los corren por nosotros, que también nos da esta capacidad de computación general. Pero la cuestión es, bueno, vos me llamás a mí, me llamás a la lógica que yo implementé por fuera de tu plataforma, pero cuando yo te quiero decir de nuevo a vos no sé, mostrar un mensaje de error o anda a esta página o esta es tu nueva foto de perfil. Digamos, ¿qué te puedo yo? O sea, vos me llamás a mí y yo puedo hacer cualquier cosa, pero ¿qué puedo hacer yo llamándote de vuelta a vos? O con la respuesta que yo te envío de vuelta, ¿qué posibilidades hay? O sea, que no es solo que pueda hacer un request HTTP, sino es desde mi código general, ¿qué puedo hacer de nuevo en la plataforma? Entonces ver que si tienen una API o si interpretan lo que yo les devuelvo, qué es lo que es posible. Porque muchas veces lo hacen como una forma de tiquear un checkbox en las features. Hey, si nuestra herramienta no soluciona tus problemas, podés hacer un request HTTP. Sí, pero luego, ¿qué puedo hacer de vuelta desde mi código hacia la plataforma? Ese es, digamos, los 2 red flags a tener en cuenta en cualquiera de este tipo de plataformas.

Me ha hecho pensar porque recuerdo que, o sea, con esto de las peticiones HTTP, una de las complejidades accidentales mayores es tener un servidor web con toda la parafernalia que ello conlleva. Y recuerdo las típicas siglas de Platform as a Service, Infrastructure as a Service, pero ahora se está poniendo también muy de moda el Function as a Service que Amazon Amazon tiene su principal producto que se llama Lambda, que te permite poner ahí tu código y entonces se acciona con una petición, hacer esa ejecución y se retorna algo. Entonces alguien que quisiera extender su código low-code podría utilizar un Function as a Service directamente y le facilitaría, le quitaría esa complejidad accidental.

Sí, es normalmente hacia donde tiende a ir todos los puntos de extensiones, functions as a service, funciones como servicios. Y el primero en hacerlo fue Amazon con Lambda. Pero como todo, se intentan distintos puntos en el espectro de low-code, no-code. Y los 2 más interesantes en el espectro low-code de eso para mí son, bueno, ahora hay uno nuevo que no lo probé, pero Replit. Que nos permite— que empezó como un servicio en el cual uno tenía una consola interactiva de Python en el navegador, pero ahora uno puede correr pequeños servicios y ellos los corren por nosotros. Simplemente vamos a la página de Replit, escribimos nuestro server HTTP y ellos lo corren por nosotros. Que ese sería low-code, pero bastante code, por decirlo así, porque tenemos cada proyecto es ficheros y directorios y escribimos un servidor HTTP. Yéndonos más en el espectro low-code, hay uno que se llama Valtown, v-l.town, T-O-W-N, en el cual restringen más. O sea, cada uno de nuestros handlers es de cierta manera casi una función o un valor, y digamos, y se espera que cada uno de esos que creamos es un endpoint HTTP. Podemos adentro hacer un poco de lógica y tener más de uno, pero lo que se espera es uno crea uno de esos valores y adentro escribe lógica para un endpoint y nos hace el chequeo de— se escribe en JavaScript o TypeScript, nos hace el chequeo de tipos. Ahora tiene soporte para un bot de inteligencia artificial y cada vez que guardamos el valor instantáneamente está disponible como un endpoint. No hay un concepto de hacer deploy, redeploy, stop, start. Siempre que salvamos, esa es la versión que está corriendo en producción. Y esos son dos, de hecho son tres. Ahí podemos ver cómo la solución al mismo problema lo podemos encarar desde code, porque si bien Amazon Lambda es una sola función como servicio, de cierta manera es lo mínimo que podemos expresar. Es un proyecto en nuestra computadora, que es un directorio con un unos cuantos archivos que dicen cuál es la función, cuál es el entry point, cuál es la configuración, cómo se llama, lo que fuera, credenciales. Y si queremos que eso esté disponible en producción, tenemos que correr un comando para subirlo al servidor de Lambda y esperar un par de segundos a que esté disponible. Replit es, OK, ¿qué pasa si en el lugar en donde vos editás ese Lambda no es en tu computadora, sino que es en nuestras computadoras? Y simplemente apretás un botón restart y nosotros nos tomamos el trabajo de tenerlo disponible. Y el tercero es qué pasa si no te damos un proyecto, un directorio, sino que te damos un editor de texto, y lo que está en ese editor de texto es lo que corre en producción. ¿Y cuándo corre en producción? Siempre. ¿Y qué corre en producción? Lo último que guardaste. Y es como explorar cómo hacemos Function as a Service en code, low-code y lowest-code, porque menos que eso no se puede hacer. Ya iríamos a no-code, diríamos no estamos programando en JavaScript, sino que estamos escribiendo que programan en algo más restringido. Y son 3 exploraciones del mismo problema en distintos puntos del espectro. Y de nuevo, como digo, no hay uno que sea mejor o peor que el otro. Es sin que me digas cuál es el problema que estás tratando de solucionar. Yo siempre voy primero a ValTown porque es el más fácil y más rápido. Y si necesito algo más complejo como traer dependencias o programar en otro lenguaje que no sea JavaScript, o gestionar de cierta manera el servidor, o usar un framework, podés ir a Replit. Y si ya necesitás algo un poco más enterprise, te vas a Amazon. Pero normalmente lo que uno hace es primero va a lo más fácil y después va encontrando por qué no puede usar eso y se va moviendo en el espectro hacia el código.

Pero revisando el mundo de la domótica, porque a esta gente también le ha dado mucho por el no-code y el low-code, Estaba revisando que muchas de estas conectan los sensores y este tipo de dispositivos de Internet of Things directamente a herramientas como Zapier, LateNote, o incluso una que es If This Then This.

Tal vez esa es la más no-code de todas, If This Then That, porque la idea inicial fue evolucionando un poco, pero se mantiene bastante fiel. Literalmente está en el nombre, if this then that. Entonces uno al principio puede decir si subo una foto a mi Instagram, postéala en Twitter. If this then that. Decimos qué era la precondición y qué era la poscondición. Y lo que uno podría poner en la precondición y la poscondición eran 15, 20 bloques. Con el tiempo obviamente fueron creciendo la cantidad de bloques. Después tenemos Zapier, que es como un if this then that pero bastante más poderoso, por lo cual más complejo, pero digamos todavía no-code, en lo cual digamos no es una precondición, una postcondición, sino que podemos tener muchas precondiciones y muchos pasos en la postcondición. Y cada uno de los pasos en la postcondición es una integración con un servicio externo en el cual cada uno puede tener un montón de campos de configuración. Y después tenemos todavía ahí, ya como te digo, no es, no es un espectro unidimensional, sino que es multidimensional. Sentí que hay un proyecto que se llama Node-RED, que es, justo mencionaste Internet of Things, que es un lenguaje visual con nodos y cables para programar, que se usa mucho. Y creo que inició inicialmente era de Internet of Things, que se usa mucho para domótica y cuestiones así, para programar reglas, para automatizar cuestiones relacionadas con la domótica y con el Internet of Things, que es un lenguaje, digamos, visual, como digo, de nodos y cables, que es muy común terminar en esa abstracción en el mundo no-code. Pero como Scratch, digamos, lo que hace cada uno de los nodos es bastante cercano a la programación. Tenemos variables, tenemos funciones, tenemos condicionales, tenemos loops, y son todos como también esos 3 son como exploraciones en el espectro más de no-code, en el cual digamos restringen bastante a qué tipo de input podemos reaccionar y restringen bastante qué podemos hacer una vez que recibimos el input. Pero bueno, lo mismo, si lo único que quiero hacer es cada vez que posteo una foto en Instagram postear en Twitter y uso if this then that, ¿por qué voy a hacer algo más complejo? Pero bueno, Zapier se usa mucho para tipo de integraciones entre herramientas de software as a service en empresas Pues decimos cada vez que no se cambia de estatus algo en Jira quiero no sé hacer un correr un test en algún otro lado abrir un ticket en otra cosa cerrar algo mandar un mensaje en Slack ese tipo de cuando pasa algo en un sistema quiero hacer algo en otro sistema es muy común que se use en Zapier.

Y ahora yendo a la otra parte de que estábamos hablando desde el principio. Yo recuerdo que desde hace un tiempo, como todo se ha vuelto navegador, incluso hay portátiles, los Chromebooks, que directamente arrancan el sistema operativo y te plantan el navegador, y ahí lo tienes todo. Entonces ha llegado un momento en el que tanto los videojuegos como sistemas de cálculo complejo y otra serie de desarrollos, ya JavaScript se les queda pequeño. Es decir, no todo puede tirar con ese lenguaje de programación, necesitan más rendimiento. Y entonces han recurrido, según creo, a una herramienta o a una forma de programación que la llaman low-level code dentro del navegador o dentro de otros sistemas remotos. ¿Cómo funciona esto más o menos?

Sí, justo ahí, cuando estabas mencionando eso, me hace dar cuenta que JavaScript empezó como un lenguaje low-code. La idea de JavaScript en el '95 en Netscape era, en esa época las páginas eran documentos y no tenían ningún tipo de interactividad, y contrataron a Brendan Eich, el creador de JavaScript, para decirle ok, necesitamos que crees un lenguaje programación chiquito de scripting, que en esa época y sigue significando un poco lenguajes que se usa para escribir programas chiquititos, que le permita a los programadores, a los diseñadores, desarrolladores de páginas web agregar cierto nivel de interactividad en las páginas que no es navegar, que no es clickear en un link. Entonces, ¿qué pasa si, por ejemplo, si tengo un formulario y quiero validar algo? O si quiero, cuando aprieto un botón, esconder algo, mostrarlo, o hacer algo que no sea la navegación natural de navegar. Inicialmente uno escribía el código JavaScript en el HTML. El onclick, onSubmit, escribe entre comillas y escribe el código una línea nomás. Entonces digamos es curioso que JavaScript, si bien empezó como una herramienta low-code, ahora es bastante code. Y por eso que mencionas de donde JavaScript se empieza a quedar un poco corto es como sus orígenes eran un lenguaje de scripting para agregar un poco de interactividad a las páginas, nunca fue diseñado con la intención de ser particularmente performante o eficiente en el uso de los recursos. Si bien, digamos, Google y otros han gastado millones y millones y millones de dólares en tratar de hacerlo eficiente y rápido, que han logrado bastante, todavía no lo es, particularmente en todas las cuestiones que tienen que ver con cálculo numérico. Entonces hace ya bastantes años, como más de 10 probablemente, en Mozilla empezaron a experimentar con cómo podían ellos compilar de alguna manera proyectos de C/C++, particularmente juegos que corren en el navegador. E hicieron un experimento bastante particular que se llama en su momento Assemblage, que era qué pasa si agarramos una representación intermedia del compilador de Clang y en vez de compilarlo al lenguaje de bajo nivel de ejecuta una computadora, lo ejecutan, lo compilamos a un subset de JavaScript que en ese momento se llamaba asm.js. Y digamos, si nosotros sabemos que el JavaScript que estamos ejecutando es este subset, podemos aplicar un nivel, una cantidad de optimizaciones que no podríamos si estamos ejecutando JavaScript completo. Con eso hicieron una demo que se llamaba algo así como Citadel, que corrieron, compilaron un juego, una demo de un juego de Unreal Engine y lo corrieron en Firefox y generó bastante interés porque fue la primera vez que había un juego bastante potente corriendo en el navegador. Y tratando— trataron de ir a los otros navegadores, Chrome y Safari, y decirles, hey, ¿por qué no implementan este subset de JavaScript en sus navegadores? Y los otros desarrolladores le dijeron, si vamos a hacer esto, es medio un hack, digamos. ¿Por qué en vez de estandarizar este hack, que es un hack bastante interesante, Pero ¿por qué no lo hacemos bien? Entonces se creó lo que se llama WebAssembly, que es un bytecode, una representación binaria de un lenguaje de bastante más bajo nivel que JavaScript, pero que mapea bien al tipo de código que generan lenguajes de bajo nivel como C, C++ y ahora Rust. Y eso fue WebAssembly 1.0. Eso ya está disponible en todos los navegadores y permitió por ejemplo Figma o Adobe Photoshop, ahora compilan proyectos de C++ y los corren en el navegador. Y la mayoría de esos hacen muchos juegos ahora en, ¿cómo se llama este engine que no es Unreal de videojuegos? El otro, Unity. Hay un botón tipo deploy to web, siempre y cuando uno cumpla con ciertas precondiciones, lo compila directamente al navegador. Y la penalidad de performance comparado con ejecución nativa es de 20 por nivel de 20%. Pero eso fue lo que se llama WebAssembly 1.0. Y todos los programadores que no programan, que tiene de particular estos 3 lenguajes que mencioné, C, C++, Rust, es que no tienen lo que se llama un garbage collector. O sea que uno gestiona la memoria manualmente en esos lenguajes, y eso permite compilar a instrucciones de bastante bajo nivel. En contraposición a los lenguajes que tienen un garbage collector, que cada lenguaje que tiene un garbage collector tiene una implementación propia con abstracciones propias, con representaciones propias, con reglas propias, semánticas propias. Entonces lo que pasa es al nivel de memoria escribiendo bytes en memoria todos podemos interoperar porque es fácil, lees un byte, lees un entero o no mucho más, pero si yo tengo una referencia a un valor en JavaScript y tengo una referencia a un valor en Python esos valores no pueden interoperar porque están en 2 heaps distintos con representaciones distintas Entonces lo que se empezó a trabajar después de la versión 1.0 de WebAssembly es podemos estandarizar una representación de estos valores para lenguajes con garbage collection y que todos los lenguajes puedan compilar a esa representación. Y eso es lo que se está terminando de estandarizar ahora y lo que va a permitir, o sea, hasta ahora lo que uno puede compilar a WebAssembly son librerías o funcionalidades de lenguaje que están en C, C++, o en Rust. O lo que uno normalmente hace cuando ve un proyecto que compila, no sé, Python o JavaScript, lo que hacen es compilen el garbage collector del lenguaje y lo ponen adentro del módulo. Eso hace que el módulo de WebAssembly generado sea muy grande porque lo que tiene adentro es un runtime del lenguaje entero, o sea, tiene el intérprete entero del lenguaje adentro del módulo, que es muy interesante que eso funcione, pero lo que hace es que uno tiene que descargar, no sé, 10 megabytes con todo el runtime de Python o de JavaScript para poder ejecutar el código. Lo que se está internalizando ahora es, no compiles todo el runtime, compilá esta representación y digamos WebAssembly ya te provee el runtime. Todos compartimos el mismo runtime. Y la otra cosa que es interesante es que uno puede pasar una referencia, no sé, de una lista de Python a JavaScript, o si uno quiere interactuar con Por eso también una cosa que decepciona un poco a la gente que empieza con WebAssembly es, ok, pero ¿cómo hago? ¿Cómo interactúo con el DOM en WebAssembly? Y no se puede porque el DOM es un objeto JavaScript y eso es un objeto que está en el heap de JavaScript que tiene una representación en memoria particular para el runtime ese, y WebAssembly no sabe de referencias y de objetos y de heaps y de garbage collection. Entonces es muy difícil crear aplicaciones 100% web con WebAssembly. Hay una parte que uno la va a terminar haciendo en JavaScript, y lo que se está tratando de hacer con esta versión 2.0 es que JavaScript nos pueda pasar una referencia a un nodo del DOM y que nosotros en WebAssembly podamos interactuar con, acceder a los atributos, modificarlo, o hacer crear propias instancias y devolverlas. Es que digamos poder que objetos en el heap de un lenguaje con garbage collector puedan cruzar la barrera de WebAssembly. Y todavía no sé cuándo va a salir el estándar, probablemente 2025, pero ya está disponible en muchos navegadores. De hecho, sí hay un lenguaje Dart que tiene un framework que se llama Flutter, que hoy en día uno ya puede compilar a WebAssembly con garbage collection y correrlo en un navegador. Porque digamos, si bien la versión final del estándar todavía no se ratificó, la mayoría de los navegadores ya tienen la funcionalidad implementada. Así que va a ser un año interesante para la gente que sabe de lenguajes de alto nivel y que hasta ahora ve que los únicos que pueden jugar con WebAssembly son la gente que programa en lenguaje de alto nivel.

Muy interesante, la verdad. Pues ya llevamos casi una hora, bueno, una hora prácticamente. Así que si quieres decir algo para finalizar que se nos haya quedado un poco en el tintero.

Sí, es un poco en inglés esto, pero les recomiendo también que aprendan inglés. Es una forma de acceder también a cierto— hay mucho contenido que muchas veces no se traduce. Ahora con los LLM, por suerte, hay más cosas que se vuelven accesibles. Pero soy miembro de una comunidad que se llama Future of Coding, donde hay gente explorando todos los puntos de este espectro de no-code, low-code y code, y alto nivel y bajo nivel. Y mantengo la página de futureofcode.org y mantengo el newsletter semanal para la gente que no puede seguir la comunidad de Slack día a día. Una vez por semana sale un mail con un resumen de la actividad de la semana de la comunidad. Y si les interesa explorar otras formas de programar que no sean las más tradicionales, les recomiendo que pasen por ahí.

Agregaremos todos los enlaces que hemos ido diciendo en la descripción. Pues Mariano, muchas gracias por haberte pasado y habernos dado tanta información sobre este mundo. Me parece muy apasionante.

Gracias a vos.

Y aquí dejamos ya el capítulo de Codeadores. Muchas gracias por haber estado con nosotros y nos vemos la semana que viene. Gracias por estar ahí.