Hablemos de NIM

Tenéis que admitir que tenemos seguidores con muy buen criterio.

¡Y tanto! Uno de los vídeos más vistos es el vídeo de Go.

El vídeo más visto es el de C++, así que totalmente.

Sí, sí, pero tenéis que reconocerlo sobre los últimos vídeos que hemos publicado. El vídeo de Python sobre Guido van Rossum ha sido uno de los más vistos. Y hoy hablamos de Nim. Que por cierto, hay que dar un agradecimiento especial a Robinson, Marlon, Vujakievic y Álex, que fueron los que más votaron por esta opción. Gracias, chicos.

Nim tiene sus raíces en Python, pero no lo consideraría dentro del ecosistema de Python. No al menos como Mojo, que puede utilizar las dependencias de Python directamente.

Pero Mojo no es aún software libre.

Pero es gratis.

No es lo mismo, Chip. Es mejor que sea libre a que sea gratis.

¡Protesto, señoría!

Vamos a centrarnos en Nim. Comenzaremos por sus orígenes allá por 2005.

Pero no olvides que antes tenemos un inciso.

¿Te gustaría decidir los temas que trataremos en el canal?

Pues lo tienes muy fácil.

Entra en nuestra página web, accede con tu cuenta de Google y vota por tu favorito.

Puedes votar una vez al día para que gane el tuyo.

Eso no es trampa.

Serán tomadas en cuenta todas vuestras sugerencias en comentarios, en publicaciones y vídeos además.

Y ya que estamos, ¿por qué no darle me gusta, suscribirse y hacerse miembro?

Eso ya saben cómo hacerlo, Violeta. Estamos hablando de votos.

Totalmente. Hagamos que ganen esos lenguajes de bajo nivel, chicos.

Sigamos con el vídeo.

Aquí falta algo. Andreas Ramph comenzó el desarrollo de Nimrod en 2005, como decía Pro. Nimrod, así es como se llamó inicialmente. Luego llegaremos a la parte del nombre.

Vale, perdón.

Andreas consideró que no había un lenguaje de sistemas que aunase características que él adoraba de Python, Ada y Lisp, así que comenzó a escribir este lenguaje usando Free Pascal.

El compilador se hizo público en 2008 y hubo una versión de Nimrod también escrita en Nim usando la técnica de bootstrapping.

Todo lenguaje de sistemas y bajo nivel que se precie debe compilarse a sí mismo, aunque a veces es difícil concretar en qué consiste esta técnica.

No tanto. Primero se desarrolla un binario mínimo que compila lo básico del compilador y luego se utiliza ese compilador básico para compilar y generar el compilador definitivo.

¡Qué follón! Bueno, Es obvio que la sintaxis de Nim tomó mucho de Python al igual que el uso de las palabras reservadas. De Lisp tomó la precisión de su sintaxis, su sistema de tipos estáticos.

Lo ideal y correcto.

Lo óptimo.

Para evitar fallos en tiempo de ejecución y obtenerlos en tiempo de compilación, según Andreas.

No me termina de convencer del todo, pero sigamos. Ah, sí. De Lisp también su sistema de macros.

El sistema de macros de Lisp es ideal para la programación de sistemas. Andreas supo elegir bien. Ayuda a trasladar problemas que aparecen normalmente en tiempo de ejecución en otros lenguajes a problemas en tiempo de compilación.

Os habéis puesto de acuerdo pro y tu en enfatizar que es mejor obtener errores en tiempo de compilación a obtenerlos en tiempo de ejecución.

Es lo ideal, chip, y lo óptimo, chip.

Podríamos también decir que la gestión de memoria está influenciada por C++ o Rust, pero como veremos más adelante Gracias a un nuevo algoritmo para recolección de basura, esto no es así.

No olvides que al haber sido escrito en Free Pascal, algo terminó influenciando ese lenguaje también al final.

¡Cierto! Object Pascal y Oberon fueron una influencia en cuanto a la forma de implementar la orientación a objetos.

¿De Ada no tomó nada?

Seguramente lo que hace fuerte a Ada: su seguridad de tipos para el desarrollo seguro de aplicaciones y no olvides la programación genérica de C++.

Nimrod el cazador. En el diccionario de Oxford, si buscamos Nimrod, veremos que tiene como significado un gran o hábil cazador.

A menudo irónicamente. Esto tiene una curiosidad bastante buena detrás, porque parece que en los dibujos animados, cuando el cazador Elmer Fudd, que siempre está intentando cazar a Bugs—

¿Cazando Bugs? Ese no era un cazador, era un miembro del equipo de QA.

El caso es que Bugs se mofaba de él llamándolo Nimrod, y parece que con ese Con ese uso, Warner contribuyó a cambiar de forma irónica el significado de Nimrod.

No nos desviemos. El término viene del rey bíblico hijo de Noé llamado Nimrod.

El que construyó la Torre de Babel.

El primer ingeniero que no consiguió completar su trabajo por problemas en el equipo.

No era un ingeniero, era un rey. De ahí que el logotipo del lenguaje sea una corona. De hecho, se considera el primer rey de la humanidad.

Y Andreas consideró Nimrod el primer lenguaje regio.

Es tan pretencioso como decir que es un lenguaje para dominarlos a todos.

¿No os recuerda a esa tira cómica de XKCD?

En verdad, Andreas tenía miedo de que pasara con su lenguaje como pasó con otros, como Lisp, en lo que se conoce como la maldición de Lisp, que hay decenas de dialectos y uno no puede decir que sabe realmente Lisp.

Eso también pasó con los hijos de BASIC tal y como contamos en un vídeo anterior. Pero si al principio se llamó Nimrod, ¿por qué se acorta como Nim?

Ya sabes cómo son los estadounidenses, su manía de dejar todo en una sola sílaba. Si tu nombre es largo y puede recortarse, se recortará.

Eso solo tendría sentido si se acorta de forma coloquial, pero se ha recortado de forma oficial.

A Andreas le gustó la versión corta y se quedó así. Pasemos al siguiente bloque. El recolector de basura.

Todos los lenguajes de programación deberían tener un buen recolector colector de basura para ahorrarnos a los programadores tener que vigilar la memoria.

No estoy de acuerdo. Quien programa sabe en qué partes del código puede liberar la memoria y en qué partes conviene dejar ciertas reservas para optimizar su uso.

Menos mal que Andreas estuvo despierto en este aspecto y agregó una recolección de basura que fue muy novedosa desde el principio.

En principio, la recolección de basura de Nim era lo más normal que podías encontrar en otros lenguajes de programación. Incluso podemos decir que frenó la adopción de Neem para proyectos de tiempo real o de sistemas embebidos.

Pero no mucho más tarde se implementó ARC, un algoritmo novedoso para contar referencias y utilizar de forma óptima, como a Hexa le gusta, la recolección de basura.

En verdad, Chip, la publicación en el blog de Neem titulada Introduction to ARC/Orc in Neem indica que la idea fue tomada de cómo funciona el conteo de referencias en Swift.

Aunque dice que en las versiones anteriores puedes deshabilitar el recolector de basura.

Sí, pero haciendo eso no puedes utilizar la biblioteca estándar. La inclusión de este recolector de basura fue óptimo. El recolector de basura ahora es determinista y eso ayuda a poder insertar destructores en las partes del código donde el compilador sabe que dejará de utilizarse la memoria.

Con este cambio abrieron la puerta a desarrollos de tiempo real porque ya no había un elemento que detuviese el sistema para hacer una recolección de basura. Y al liberar la memoria no usada al momento, evita la acumulación de memoria y, por tanto, hace usable el lenguaje para entornos de hardware limitado o embebido.

Parece que el peso de Nim recae en el compilador.

Eso me recuerda a algo... Transpilando Nim. Hemos hablado desde el principio sobre el compilador de Nim y no soy yo tiquismiquis, pero al igual que otros lenguajes ya vistos como Glimpse y otros que aún no hemos visto como TypeScript, Nim no se compila. Se transpila a C o incluso a JavaScript.

¿JavaScript? Ya perdió mi respeto.

No es para tanto, la compilación a JavaScript es tan solo para poder tener más opciones de plataformas, como por ejemplo poder tener una versión en el navegador y así probar Nim.

Hubiese preferido que transpilase a C en un formato para WebAssembly, justo como lo hace Go.

Aunque Go es más rápido que Nim, seguro, porque compila a nativo y está diseñado para ser rápido.

Sí, de momento. Andreas comentó en una entrevista que la velocidad actual es de 21.000 líneas de código por segundo en una CPU de un solo núcleo.

La ventaja de Nim es su transpilación a un código C hecho para ser rápido de compilar. En el foro de Nim hay quien indica que sus proyectos grandes, asumimos que serán decenas de miles de líneas de código, tardan segundos frente a los minutos que suelen tardar este mismo tipo de proyectos en C++.

Si los ordenamos de menor a mayor, para proyectos del mismo número de líneas, Go es el más rápido.

¡Obviamente!

Nim es el segundo más rápido, seguido de Zig, Mojo y finalmente Rust.

Es normal, el foco de Rust está en la seguridad y no en la velocidad de la compilación.

Dejad de medirle las velocidades. Lo que hace a Nim algo más lento es su complejidad. Los genéricos y las macros se resuelven a nivel de compilador y obviamente eso toma su tiempo. Si no, Nim podría batir a Go.

De hecho, Andreas se enfocó en ir mejorando de forma progresiva la velocidad, porque según la entrevista que le hicieron, él y otros de la comunidad sabían cómo implementar ciertas mejoras.

El tiempo dirá, pero a Go no le ganan.

Características. Estuve preguntando en el grupo de Telegram de Nim qué puede ser interesante de ver acerca del lenguaje. Por cierto, os dejo el enlace en la descripción por si queréis sumaros a aprender y resolver vuestras dudas en español.

Parece que Luis Acosta hizo una buena recopilación.

Comenzamos. La similitud con Python hace posible un acercamiento al lenguaje si ya sabes Python y facilita la migración de proyectos.

Me cuesta reconocerle esto a Mojo, porque preferiría que fuese antes código abierto, pero es más fácil con Mojo. Es decir, la fricción teórica con Mojo es cero y, sin embargo, con Nim seguro que hay que cambiar muchas cosas.

A ver, esto es un caso único, pero puede servir para ilustrar lo fácil que resulta Nim y las ventajas que aporta al migrar de lenguajes como C++. El usuario de Reddit Nokretz dijo que lideró la conversión completa de su producto de C++ a Nim y las ventajas no fueron solo la velocidad, sino también la reducción de complejidad y la facilidad de agregar nuevos programadores al proyecto. Y esto me sirve para enlazar con la siguiente característica: el rendimiento cercano o igual a C.

Transpila C, es normal. Echando un vistazo parece una generación de código óptima. Es normal que no reste rendimiento.

La siguiente es la compatibilidad con bibliotecas de C, C++, Objective-C y JavaScript.

Pero esto depende de si utilizas como objetivo compilar a C para GCC a C para Clang o si compilas para JavaScript.

Totalmente. Ya te quiero ver usando una dependencia de JavaScript compilando a C con GCC.

No quiere decir que no se pueda, pero sí depende del objetivo de tu proyecto. Tal y como ha mencionado Violeta, la siguiente característica es la posibilidad de utilizar diferentes compiladores, tanto de C como para generar el módulo de JavaScript. También comentó el uso de metaprogramación mediante macros y templates. Y el resto no tiene importancia.

Uy, uy... Huele a que alguien quiere ocultar algo aquí.

¿Algo de más bajo nivel o funcional?

Tiene pinta de algo funcional.

Es la manía de introducir sabores funcionales a todo. Es como la IA, lo funcional está por todas partes.

A ver, a ver... ¡Tenemos iteradores de primera clase!

Esto quiere decir que podemos definir el comportamiento para un cierto tipo de datos cuando se somete a un bucle. En la documentación de Nim hay un ejemplo muy bueno donde implementan items y pairs. Después un bucle, al final, utiliza el tipo custom range del que extrae una pareja de términos llamando a pairs, y pairs hace un bucle donde extrae un único ítem utilizando el iterador items superior.

Hay otro uso que me llama la atención, porque en Python para la definición de funciones se usa la palabra reservada def, y aquí en los trozos de código he visto que se emplea proc Y func.

Esto parece copiado de Pascal. Ahí un procedimiento es un trozo de código que se ejecuta y no retorna ningún valor, y una función es un trozo de código que se ejecuta y retorna un resultado.

Me temo que no, pro. En este caso parece que tiene que ver con los efectos colaterales. Cuando se define un procedimiento se asume que puede tener efectos colaterales, como imprimir a pantalla o cambiar una variable global.

Eso quiere decir que las funciones puras no pueden contener efectos colaterales.

De hecho, si una función tiene un efecto colateral, el compilador falla.

Podemos decir que tiene entonces también funciones de primera clase, como en la programación funcional.

Sí, pero parece que deben ser funciones y no procedimientos.

Lo ideal es solo usar proc y así te quitas de problemas. ¿Quién usa func? Conclusiones.

¿Tan pronto, Chip? Creía que te gustaba Nim.

Sí, las partes de hacer al estilo Python el bajo nivel de forma que no parezca bajo nivel me gustan. Pero cuando saltas a la parte funcional, eso ya me aburre. No hace falta usar un sabor funcional para utilizar NIEM.

Tampoco hace falta usar la orientación a objetos. La hemos comentado, pero no hemos hablado de ella en profundidad.

Y es una pena. Andreas fue programador de Delphi y añoraba esos años de programar en Delphi. La parte de orientación a objetos seguro que tiene mucho sabor a Delphi.

Tendríamos que hacer un segundo capítulo de orientación a objetos. El que tenemos habla solo de la programación orientada a objetos de Alan Kay y no de la otra vertiente que se popularizó de C++ o incluso la empleada a partir de Object Pascal.

Herejías. Solo existe una orientación a objetos y es la plasmada por Alan Kay en el documento de Smalltalk.

Como os estáis liando mucho concluyo yo el capítulo. Nim es un lenguaje compilado, concurrente, procedural, imperativo, orientado a objetos y con metaprogramación. No olvides también funcional, que surgió para facilitar la creación de programas de bajo nivel con un lenguaje claro y fácil de entender. Ha demostrado su versatilidad en proyectos como Nimbus.

Solo Nimbus.

Me temo que el lenguaje es aún bastante joven y nadie ha pensado en escribir algo grande o de gran impacto aún con él, o no nos hemos hecho eco. Así que esa es una buena pregunta para estrenar la caja de comentarios. ¿Has oído de algún proyecto grande o mediano hecho en Nim?

¿O pequeño? Oímos y no juzgamos.

¿Os animáis a utilizar Nim para vuestro siguiente proyecto?

¡Déjanos tu comentario!

Al querer hacer una visión de historia, origen, características... no queda mucho tiempo para casi nada al hablar de un lenguaje de programación.

La idea es crear capítulos donde comentemos ciertos aspectos. Por ejemplo, la marcha de Guido van Rossum como BDFL de Python fue una gran historia.

También la forma de uso de la concurrencia. Go, que parece que no tuvo mucho tirón.

A mí me gustó más el intento de golpe de estado en la conferencia de C++ por parte de Google en la que presentaron Carbon.

Habla de nuestro capítulo de C++.

Hay que mejorar la página de votaciones. ¿Permitimos hacer sugerencias a los usuarios?

Venga, agregamos una sugerencia por día si llevan más de 30 días dados de alta y al menos 10 votaciones.

¿Vas a poner logros en la web?

Continuará.