Starting Point

The state of education and general culture regarding the internet and the World Wide Web is, to say the least, worrying. The cloud, web applications, social networks, and other byproducts of the latest evolutions of the Web (with the recent incorporation of generative AI services) form an ecosystem that people without a technical background rarely escape. Users are trained in specific interfaces to use specific products, and there are very few software tools outside this limited set that users are willing to learn. When your judgment is limited to user-level knowledge, the reasoning is understandable: why learn an alternative if I already know how to use something and it’s easier? This is the main reason why Linux and much Free Software have failed to achieve broader adoption. This is the problem we continue to face when offering free alternatives: a barrier to entry created by user-experience design and an ecosystem hostile to alternative technologies.

However, there is one exception to this rule: a type of software that is not used as a means to an external task, but as an end in itself—video games. These are not tools used with the expectation of producing results; they are run for playful, aesthetic, or purely curious interest. For this reason, they are a perfect gateway for educating the population, just as they have also been used for manipulation. Not only because the gamified content format predisposes users to absorb it, but because the game itself belongs to the very medium one wants to teach about. There is no better way to explore the possibilities and risks of a computer than from within one.

Development of dw3nd3

With this framework, the history of dw3nd3 becomes easier to understand. Initially, it was born as a lightning project after discovering twtxt. I have long been interested in web decentralization, and it was twtxt that helped me rediscover the possibility of connecting decentralized content through protocols implemented in local clients. I had known about RSS for a long time, and of course HTML; but I had forgotten the fundamental principle of the web, because every time I considered writing my own browser, I realized it was an almost unmanageable task. An RSS reader would be simpler, but it would still require a complex XML parser. By contrast, I could implement a twtxt browser in a matter of hours. After successfully doing so and rediscovering the potential of protocols based on simple rules and grammars, the question arose: couldn’t a video game be created using the same underlying idea?

It was at this point that the story of dw3nd3 truly began. When thinking about a video game that navigates web content, it made sense to think of that game as a browser. I needed a simple format—easy to implement, understand, and replicate. I drew inspiration from twtxt, as mentioned, but also from 100 Rabbits’ work on the minimalist uxn stack, from minimal educational environments such as toolbox.academy, and from digital toys like the Tamagotchi. I decided to adopt the philosophy of using constraints as a creative springboard and informally defined the principles of dw3nd3: a functional client should be implementable in at most a couple of days, for an extensible data format that prioritizes backward compatibility. In this way, future users of d33 could create their own content without fear of it becoming obsolete, or experiment with modifications to the standard in their own clients without much effort.

Then came the idea of hiding the contents of this web inside HTML pages. From there, the symbol of the duende emerged as something small and hidden; instead of web pages, the central concept would be that of duende rooms. Because the language was so small, a room could even fit inside social-media posts or comments. Later on, this idea expanded to include rooms embedded in other polyglot formats, so that the network of duende rooms could propagate not only through HTML pages, but also through code, documents, images, and more.

As I refined an initial version of the standard while working on a proof-of-concept client, I realized that a browser needed a plugin-oriented architecture to fully unleash user creativity and take advantage of the standard’s flexibility. With this in mind, I designed the first version of tr4sg0, intended as a definitive reference for other clients.

Lessons from dw3nd3

When I finished this work, I did not feel that I had truly learned something new, but rather that I had reconnected with a series of essential fundamentals as a computer scientist:

• The complexity of formal languages matters.
• The fundamental pillar of how the web works is standardization.
• Everything that exists on the web can have something hidden inside it.

In my case, this project has had a re-educational value in addition to a creative one. If I could experience these truths from scratch thanks to d33, I thought that encouraging other users to create their own rooms, plugins, and even clients could do the same for them.

We need to understand the web again, to revalue simple, replicable, and standardized software, and to understand the nature of the information that travels across the network. In all of this, dw3nd3 is only a small personal, creative, and experimental project—but it is born from that same awareness and aims to make its own small contribution.

El estado de la educación y la cultura general con respecto a internet y a la www es, como poco, preocupante. La nube, las aplicaciones web, las redes sociales y otros subproductos de las últimas evoluciones de la Web (con la reciente incorporación de los servicios de IA generativa), forman un ecosistema del que rara vez escapa la gente sin trasfondo técnico. Se entrena a los usuarios en interfaces específicas para que utilicen productos específicos, y son pocas las excepciones de herramientas software que los usuarios están dispuestos a aprender a utilizar, fuera de este limitado conjunto de productos. Cuando tu criterio está limitado a un conocimiento de nivel usuario, el motivo es razonable: ¿por qué aprender una alternativa si ya sé usar algo y es más fácil? Esta es la principal razón por la que Linux y mucho Software Libre no consigue una mayor adopción. Este es el problema al que nos seguimos teniendo que enfrentar para ofrecer alternativas libres: una barrera de entrada en los diseños de la experiencia de usuario y un ecosistema hostil a las tecnologías alternativas.

Sin embargo, hay una excepción a esta norma, un tipo de software que no se utiliza para una tarea externa, sino como un fin en sí mismo: los videojuegos. Estos no son herramientas que se usen esperando unos resultados, sino que se ejecutan por un interés lúdico, estético o por curiosidad. Por eso, son una puerta de entrada perfecta para educar a la población, como también lo han sido para su manipulación. No solo porque el formato del contenido gamificado predispone al usuario a su asimilación, sino porque el propio juego pertenece al medio sobre el que se quiere educar. No hay mejor manera de explorar las posibilidades y riesgos de un ordenador que desde uno.

Desarrollo de dw3nd3

Con este marco, se entiende mejor la historia de dw3nd3. En primera instancia, nació como un proyecto relámpago, después de conocer twtxt. Llevo mucho tiempo interesado en la descentralización de la web, y fue twtxt lo que me redescubrió la posibilidad de conectar el contenido descentralizado mediante protocolos implementados en clientes locales. Hace mucho que conocía RSS, y lógicamente HTML; pero había olvidado el principio fundamental de la web, porque cada vez que me planteaba escribir mi propio navegador, me daba cuenta de que era una tarea casi inabarcable. Un lector RSS sería más sencillo, pero siempre necesitaría un parser complejo para el XML. Sin embargo, podía implementar un navegador de twtxt en unas horas. Después de hacer con éxito dicha implementación y redescubrir el potencial de los protocolos basados en reglas sencillas y gramáticas simples, me vino la pregunta de si no podría crearse un videojuego que utilizase la misma idea de base.

Fue en este punto donde comenzó la historia de dw3nd3. Al pensar en un videojuego que navegara por contenido en la web, lo lógico era considerar dicho videojuego como un navegador. Necesitaba un formato sencillo, para que fuera fácil de implementar, entender y replicar. Me inspiré en twtxt, como he mencionado, pero también en el trabajo de 100 rabbits con su stack minimalista de uxn, en entornos mínimos de enseñanza como toolbox.academy y a jueguetes digitales como el tamagotchi. Decidí adoptar la filosofía de usar las restricciones como trampolín creativo y definí informalmente los principios de dw3nd3: un cliente funcional debía ser implementable en un par de días como máximo, para un formato de datos extensible que priorizara la retrocompatibilidad. De esta manera, los futuros usuarios de d33 podrían crear su propio contenido sin miedo a que se quedara obsoleto, o a probar modificaciones en el estándar con sus propios clientes sin mucho esfuerzo.

Después vino la idea de poder esconder los contenidos de esta web en las páginas HTML. A partir de ahí, apareció el símbolo del duende como algo pequeño y oculto; en lugar de páginas web, el concepto central sería el de habitaciones duende. Al ser un lenguaje tan pequeño, una habitación podría caber incluso en publicaciones o comentarios de redes sociales; más adelante, esta idea pasó a incluir las habitaciones en otros formatos políglotas, de manera que la red de habitaciones duende podía propagarse no solo en páginas HTML, sino código, documentos, imágenes, etc.

Al ir refinando una primera versión del estándar, trabajando con una prueba de concepto de cliente, me di cuenta de que un navegador necesitaba una arquitectura orientada a plugins para dar total rienda suelta a la creatividad del usuario y aprovechar la flexiibilidad del estándar. Con esto en mente, diseñé la primera versión de tr4sg0, a modo de referencia definitiva para otros clientes.

Aprendizajes de dw3nd3

Al terminar este trabajo, no sentí que huiera realmente aprendido algo nuevo, pero sí que había reconectado con una serie de fundamentos esenciales como informático:

• La complejidad de los lenguajes formales importa.
• El pilar fundamental del funcionamiento de la web es la estandarización.
• Todo lo que existe en la web puede tener algo escondido.

En mi caso, he encontrado un valor re-educativo en este proyecto, además de creativo. Si yo podía experimentar estas verdades desde cero gracias a d33, pensé que animar a otros usuarios a crear sus propias habitaciones, plugins y hasta clientes, podría hacer lo mismo por ellos.

Necesitamos volver a entender la web, volver a valorar el software sencillo, replicable y estandarizado, y entender la naturaleza de la información que viaja por la red. En todo ello, dw3nd3 sólo es un pequeño proyecto personal, creativo y experimental, pero que nace de esa misma conciencia y pretende hacer su pequeña aportación para ello.

Creo que puedo recordar cada vez que he sentido la impresión de otra persona al leer su código. Y hablo de pasar a relacionarse con el código de manera cotidiana; no leer un fichero, una o dos funciones, sino a leer, día tras días, las líneas escritas por otro; a comprender un sistema de su autoría. Al hablar de textos narrativos, poéticos, diarios, cartas… la presencia de la persona nos llega a través de un lenguaje humano, el mismo lenguaje que usaría para hablarnos por la calle. Sin embargo, en el código se mezclan las imposiciones de un lenguaje formal y la definición de un algoritmo. Aun así, la personalidad del programador asoma en el conocimiento de sus herramientas, la comprensión del problema a solucionar y la forma de expresar estas soluciones, incluso cuando está mediada por convenciones y estándares. A menudo, a los programadores nos gusta que el código tenga cierto aspecto, cierta manera de leerse; eso después se convierte en convenciones de estilo, pero nace como una elección personal que persigue una subjetiva legibilidad. Incluso la ausencia de esta intención construye una identidad. Me pasa incluso cuando leo mi propio código, que tengo una reminiscencia de cómo era yo cuando lo escribí; qué me interesaba probar, con qué técnicas había adquirido soltura, o qué conocimientos no tenía todavía.

Por eso, he tenido la sensación, algunas veces, de que se crea una pequeña intimidad en esa lectura de código. Es una pequeña ventana a cómo funciona la maquinaria mental de otra persona. Cuando se trabaja en proyectos en equipo, llegas a reconocer de un vistazo al autor de trozos de código sin necesidad de preguntar. Y esta forma de conocimiento, a mí, me resulta entrañable incluso cuando maldigo a la persona que escribió semejante espagueti. Porque otras veces, si es un buen código, el autor te comunica cómo programar mejor; y cuando no lo es, llegas a compartir la confusión que pudo tener que soportar, o como mínimo, a empatizar con su nivel de experiencia, porque todos hemos empezado en algún lado.

Cuando estoy programando un sistema un poco más complejo, me da la sensación de estar sosteniendo un pequeño edificio con la mente, y que al pasarlo a código, lo dejo plasmado en él. Como cualquier proceso técnico creativo, en ocasiones tiene un punto solitario. Y al leer el código de otra persona, al ver su elección de arquitectura, qué prácticas usa y cuáles no, voy reconstruyendo el edificio que él/ella sostuvo mentalmente en algún momento. Es como ponerse en sus zapatos. Al hacer eso muchas veces, adquieres familiaridad con su forma de trabajo, reconoces cómo estructura el código, cómo nombra variables y funciones, cómo segrega responsabilidades, cuándo decide dejar de anidar condiciones, qué estructuras de datos prefiere, cómo le gusta procesar colecciones de datos, sus inclinaciones dentro de los paradigmas de programación…

El estilo de cada programador/a se parece a una especie de caligrafía, un acento al hablar o una colección de muletillas e incluso de palabrotas. No es algo que deba importar en la industria, pero sí es algo que, a veces, aparece. Y quería hablar de ello, porque desde fuera, parece que el código está libre de la humanidad de sus programadores; y no hay nada más lejos de la realidad. En la era de los LLMs, esto está cambiando; y no hago un juicio de valor, pero sí hay algo quería visibilizar. Muchas actividades humanas, aunque se deleguen en muchos casos o se automaticen para el consumo, no van a desaparecer de la vida de quienes las practican, por el simple hecho de que son inherentemente humanas; y como tecnólogo, siempre me ha parecido que programar es una de esas actividades.

I think I can remember every time I have felt the impression of another person when reading their code. And I am talking about interacting with code on a daily basis; not reading a file or a pair of functions, but reading, day after day, the lines written by another person; understanding a system they have created. When we talk about narrative texts, poetry, diaries, letters… the presence of the person reaches us through human language, the same language they would use to talk to us on the street. However, in code, the impositions of a formal language and the definition of an algorithm are mixed together. Even so, the programmer’s personality shines through in their knowledge of their tools, their understanding of the problem to be solved, and the way they express these solutions, even when mediated by conventions and standards. Often, we programmers like the code to have a certain look, a certain way of reading; this then becomes style conventions, but it starts out as a personal choice pursuing some subjective legibility. Even the absence of this intention builds an identity. It happens to me even when I read my own code, that I feel a reminiscence of how I was when I wrote it; what I was interested in trying out, what techniques I had become proficient in, or what knowledge I did not yet have.

That’s why I’ve sometimes felt that reading code creates a small sense of intimacy. It’s a little window into how another person’s mind works. When working on team projects, you can recognise the author of pieces of code at a glance without having to ask. And I find this form of knowledge endearing, even when I curse the person who wrote such spaghetti code. Because other times, if it’s good code, the author tells you how to program better; and when it’s not, you get to share the confusion they may have had to endure, or at least empathise with their level of experience, because we all started somewhere.

When I am programming a slightly more complex system, I feel like I am holding a small building in my mind, and when I translate it into code, I leave it imprinted on it. Like any creative technical process, it can sometimes feel lonely. And when I read someone else’s code, when I see their choice of architecture, what practices they use and which they don’t, I reconstruct the building that they held in their mind at some point. It’s like putting yourself in their shoes. By doing this many times, you become familiar with their way of working, you recognise how they structure the code, how they name variables and functions, how they segregate responsibilities, when they decide to stop nesting conditions, what data structures they prefer, how they like to process data collections, their inclinations within programming paradigms…

Each programmer’s style is like a kind of calligraphy, a speech accent or a collection of catchphrases and even swear words. It’s not something that should matter in the industry, but it is something that sometimes just appears. And I wanted to talk about it, because from the outside, it seems that code is free from the humanity of its programmers; and nothing could be further from the truth. In the era of LLMs, this is changing; and I’m not making a value judgement, but there is something I wanted to highlight. Many human activities, even if they are delegated in many cases or automated for consumption, are not going to disappear from the lives of those who practise them, simply because they are inherently human; and as a technologist, I have always felt that programming is one of those activities.

Translated with Deepl from Código humano

De entre los distintos motivos por los que he estado tan disperso este año, está el máster en desarrollo software e IA que estoy cursando en la UMA. El TFM me está sirviendo para aprender mucho sobre algoritmos que no habría tenido excusa de investigar en otro contexto, además de interiorizar, mejor que en el grado, el modo de trabajo propio de la producción científica. Aparte de ello, he terminado un proceso de saltar entre proyectos incompletos de videojuegos hechos en Godot para aterrizar en uno que finalmente tengo perspectivas de completar; ha sido el que más lejos ha llegado, en el sentido de que he publicado una demo en itch.io; y aun con mis otras ocupaciones, tengo la motivación suficiente para cerrar una versión definitiva, e incluso moverlo, si cabe, en el activo mundillo indie de Málaga. Todo esto, junto con otras cuestiones personales, me mantienen alejado de otros hábitos como escribir en mi página web o mantener mis proyectos de código abierto. A pesar del desinterés que puede aparentar la inactividad online (en esta era más que nunca), sigo teniendo muy presentes los textos por completar y los repositorios FOSS por actualizar (especial énfasis en Candle, Milua y Unofficial Openmath).

Lo que espero y deseo para este año que viene es cerrar satisfactoriamente estos dos proyectos (el TFM y el videojuego), para volver a estos viejos hábitos que están en pausa; e incorporar a estos un nivel creciente de seniority, que intento construir no sólo en el ámbito laboral, sino en todas las áreas de aplicación de mis valores sobre la tecnología. Todo ello, en parte, inspirado por pertenecer al lado humano de Internet.

¡Feliz año!

Soon, almost two years ago, I published a short summary of my experience writing this blog, with the idea that switching platforms would help me find an audience that connected better with me. What changed, however, was more my own attitude towards the activity of writing.

In these two years I have only written three blog posts (the period when I wrote weekly is long gone) and that has allowed me to focus on other more elaborate texts that had been on the back burner for some time. Unlike these publications, these texts have been written in Spanish and have taken me several weeks or months each, with a very small and close audience in mind. By separating them from my usual publications and writing them for myself, I have also been able to perceive my writing with a new perspective. I have realised that different needs require different texts, and that part of the identity crisis of my blog so far came precisely from not being clear about its specific purpose.

Looking back over my past posts, I realised that sometimes I wanted to share my latest learnings, sometimes I wanted to produce content to serve as teaching material, often I wrote about ideas I wish I had received in my early stages of engineering education, and lately I was trying to explore new ways of presenting my more personal interests. My intention from now on is to separate these needs so that the blog serves a more relatable and contextualised type of text (what a blog traditionally is).

On the other hand, I have had to come to terms with the fact that I can’t write everything in English. I think more clearly in Spanish and will most likely switch to writing in both languages, depending on what I write and when I write it. I still plan to try automatic translation of posts, though (this one has been translated automatically, for example).

The blog and my website

As I said in that post, I was trying to build a minimal online presence to compensate for the lack of work experience before I graduated. Predictably, this recent years of employement have changed that intention. I’m not sure if that presence was ever of any use, but what is clear to me is that that purpose is no longer what I want for my blog or, in general, for my website. I now intend to put it to a more complete and personal use. Moreover, having learned about the concept of POSSE I also want to make it the central node of my web presence. This, together with a new revamp of the site, which includes a new migration of the blog to self-hosting, constitutes my new way of approaching my online presence. The revamp also includes a new section where I’ll keep these other texts I mentioned earlier.

With a relaxed attitude towards what I write, I know I will enjoy running this blog more, focusing less on making myself employable or gaining an audience, and more on building a record of what I learn and what I want to share.

Introduction - Programming as talking to a machine

When I was learning to program, my university teachers used to present programming as a way to communicate with a computer. Compilers are translators between high level programming languages (closer to human languages) and machine language, binary encoded in metal circuits; therefore, to program is to talk with a computer. Obviously, this definition is not wrong, but in the software development industry context, it is clearly reductionist, as it ignores many other factors involved in development. However, this is precisely the approach that most academics I’ve worked with take, deliberately or not.

Academy and industry

The reason for this difference between industry and academy is the fundamental understanding of what programming is and, as a consequence, what life cycle of software is.

In the academy, programming is a tool to build systems that model a theoretical problem, that solve particular tasks, that embody specific demonstrations or proofs. Projects evolve from simple scripts to bigger systems, usually written collaboratively between professors, doctoral candidates and inexperienced, unsupervised, recently graduated students, neither of whom uses to care much about long term maintainability. This, along with a general lack of supervision, results in partial or absolute absence of tests, absence of style conventions, inconsistent coupling levels across the architecture and other usually considered bad consequences.

On the other hand, industry software development takes programming as a tool to build products that need to meet requisites set by clients and changing markets. Projects might last for many years and will be developed, extended, refactored and maintained by very different developers over the course of time. In the industry, this software is alive and evolving. Therefore, its architecture must be able to adapt and grow by the hand of whole teams that may also change over time.

For this reason, projects that come from the academy to find a place in the market will eventually face a complete readjustment if they want to survive. However, not all software is meant to end up in the market. Not all projects are born to live long lives, to be built collaboratively or to evolve at some point. If a piece of software works and no one is meant to ever touch it again, apart from maybe the original creator, then complex architectures, coding conventions and best-practices can be an unnecessary overhead. It is very important to identify the expected cycle of life for a program, to be objective about how it will need to be maintained.

Programming as a dialogue

The first time I was told my code sucked was in an issue on one of my open source projects, where the developer in question told me, with no offense intended, that the unreadable code made it hard to contribute. I always tried to make my code readable, how could someone not understand it? So I went to the mentioned piece of code and, what a shame, it was ten times more unreadable than I remembered: obscure variable names, deep levels of nesting in control structures, walls of code without either comments or subroutine division… Basically, they were right.

I didn’t take time to improve it. In the end, it’s an open source library used by very few people and contributed by even less, and I had better things to do. But a year or two later, I landed a new job and my new co-worker told me, during my first code review: “You are not used to writing code in a team, right?”. Since he had seen I was willing to learn, he had a very good attitude towards me and showed me the clean code practices that the team followed. However, that particular question stuck with me. It was not my first job, but it was, indeed, the first time I was going to write code, on which my income would depend, that other people would be working with.

I came to the realization that, when I wrote code without supervision (for personal projects or in a solo team) my inner discourse would go on like a monologue. As I internalized at university, I was just talking to the computer. After that code review and more that came after, I was required to have an inner discourse that worked as a dialogue. I had to talk to the machine but also to my teammates. But, how is that done through code?

Langue vs Parole

In linguistics, there’s a difference between langue and parole. The first one is the common code use to communicate with others (the language), and the second one is the particular way it’s used by an individual. For this difference, if you happen to be in the bus and listen to a conversation between two close friends, you might hear a lot of things that you don’t understand, even though they are speaking the same language as you. Not only because you may lack context, but because (oversimplifying) their specific use of language might be alien to you. The same happens with code.

If you alone are communicating with the computer, there is no problem to write code as a monologue. As far as I know, this is pretty frequent, for example, in indie game development. Some great indie games, like Undertale, are said to have terrible codebases. Given that many indie developers learn to code during the development of the game itself, it is not something strange. But, in the end, it doesn’t matter at all. The game is finished, machines run it and people play it. There would be absolutely no point in rewriting the game only for it to follow industry best-practices. The same happens with some university projects. Once you have processed a dataset and extracted what you needed, or once you have tested the algorithm you were developing, a new architecture won’t make any improvement on your desired results.

However, if you work in a team and follow this “monologue approach”, you will end up with serious problems. And when I say team, I also mean open source contributors or future maintainers for solo projects. Interpret it in a broad sense. The codebase receives input from several channels that, the same way as in the bus example, exclude others from the conversation. Your teammates will need to understand the language and your use of it to comprehend the code. This will be aggravated with each new contributor that joins the project.

To avoid that, conventions are needed. Because, let’s be real: even the most self-explanatory code can reach a point of complexity that require outside explanations, at the very least for inexperienced members of the team. Every developer that says otherwise is just assuming a level of experience and knowledge of industry standards that not everybody (starting with me) has reached yet. So, the conventions must include design patterns, code styling, nomenclature and even testing philosophy. Choosing the conventions that adjust the best to both the project requirements and the used technologies, and effectively communicating them to the other developers (usually via documentation or onboarding processes), can make the definitive difference for a project in the long term.

Needless to say, it is not all about choosing the perfect conventions, that, to start with, don’t exist. Unclear or changing requirements, too simple or too complex architectures, and many other factors are also determinants of this long term maintainability. Again, software development is a complex activity with many factors involved.

Conclusion - Ensuring conventions

As in any form of communication, the code conventions chosen for a team and a project may be sometimes interpreted in different ways or with varying levels of rigor by each programmer. Subjectivity is like that. Therefore, code reviews become an inseparable part of the said conventions’ proper application. What is legible for you may (and will) not be legible for others. So having more eyes on the code is a good way to make it more accessible. Both giving and receiving feedback on written code must be handled with humanity and an open mind.

Most of the time, basic arithmetic is pretty simple and intuitive. Even working with powers and roots isn’t that much of a headache. However, the IEEE standard for floating-point numbers includes special values that can mess things up: NaN (Not a Number), positive infinity and negative infinity. In fact, most algebraic properties of real numbers are no longer valid. The only purpose of this post is to show some cases I found interesting, where these values produce counterintuitive results.

Cover image by Armand Khoury from Unsplash

Standard behavior of NaN and Infinity

• For all x: NaN > x is false.

• For all x: NaN < x is false.

• For all x: NaN == x is false.

• For all x: NaN != x is true.

• For all x except NaN and +Infinity: +Infinity > x is true.

• For all x except Nan and -Infinity: -Infinity < x is true.

• Infinity / Infinity = NaN

• Infinity * 0 == NaN

• Infinity - Infinity == NaN

• Any other arithmetic operation between a number and Infinity results in Infinity (with a possible change of sign).

• Any other arithmetic operation between a number (or Infinity) and NaN results in NaN.

Everything I will tell you from now is trivially deduced from understanding the list above; in other words, if you understand all its implications, I won’t tell you much new. Anyway, I think it is interesting to review some side effects that may escape from us when we don’t keep them in mind.

Broken properties

The following is a non-exhaustive list of properties that we use to expect while programming, but are no longer true due to the existence of NaN and Infinity. I will provide the statement of the property (which doesn’t hold) and then a piece of code in JavaScript and Python that implements a check for it, followed by a call that returns false.

Note: JavaScript produces NaN and Infinity values easily, not only because they are native values but because they result from regular operations (Math.sqrt(-1) or 1/0). In the case of Python, they are implemented in the math library (math.nan and math.inf) and operations that would produce them (math.sqrt(-1) or 1/0) will raise an exception. For this reason, assume the following header in each Python snippet.

from math import nan, inf

Disclaimer: The snippets of JavaScript will also fail with values like strings or objects. I’m not trying to make any point about errors in JavaScript. The point is about the NaN and Infinity values, which belong to numeric types in any language with full support for the IEEE standard.

Now, behold the fall of the tautologies.

Identity

Let’s start with the most obvious and painful.

function identity(x){
    return x == x
}
identity(NaN)

def identity(x):
    return x == x

identity(nan)

Some of the following are direct results of this.

A list can’t contain elements that aren’t equal to any element

Sorry for the apparent redundancy in the statement: check the examples to see what I mean.

function checkIncludesEqual(arr, x){
    if(arr.includes(x)){
        return arr.some(e => e == x)
    }else{
        return true
    }
}

checkIncludesEqual([1, 2, NaN], NaN)

def checkIncludesEqual(arr, x):
    if x in arr:
        return any(x == e for e in arr)
    else:
        return True

checkIncludesEqual([1, 2, nan], nan)

The max value of a list is greater than or equal to the rest

function checkMaxIsGE(arr){
    let maxVal = Math.max(...arr)
    return arr.every(x => maxVal >= x)
}
checkMaxIsGE([-1, 0, 1, NaN])

def checkMaxIsGE(arr):
    maxVal = max(arr)
    return all(maxVal >= x for x in arr)

checkMaxIsGE([-1, 0, 1, nan])

The min value of a list is lesser than or equal to the rest

function checkMinIsLE(arr){
    let minVal = Math.min(...arr)
    return arr.every(x <= minVal >= x)
}
checkMinIsLE([-1, 0, 1, NaN])

def checkMinIsLE(arr):
    minVal = min(arr)
    return all(minVal <= x for x in arr)

checkMinIsLE([-1, 0, 1, nan])

Dividend equals divisor times quotient

This is the first we learn about division. D / d = Q implies D = Q * d. Well… no more. This example can only be shown in JavaScript because Python prevents division by zero.

function checkDdQ(dividend, divisor){
    quotient = dividend / divisor
    return dividend == quotient * divisor
}
checkDdQ(1, 0)
checkDdQ(1, Infinity)

The square of a value is either greater than or equal to itself or less than one

function checkSquareIsGE(x){
    return x*x >= x ||  x*x < 1
}
checkSquareIsGE(NaN)

def checkSquareIsGE(x):
    return x*x >= x || x*x < 1

checkSquareIsGE(nan)
checkSquareIsGE(inf)

“Less than or equal to” is equivalent to “Not greater than”

I find this particularly disturbing, not sure why.

function checkLEQisNGT(x){
    return (x <= 10) == !(x > 10)
}
checkLEQisNGT(NaN)

def checkLEQisNGT(x):
    return x <= 10 and not x > 10

checkLEQisNGT(nan)

A value divided by itself equals one

function checkBetweenSelfIsOne(x){
    return x/x == 1
}
checkBetweenSelfIsOne(NaN)
checkBetweenSelfIsOne(Infinity)

def checkBetweenSelfIsOne(x):
    return x/x == 1

checkBetweenSelfIsOne(nan)
checkBetweenSelfIsOne(inf)

A value minus itself equals zero

function checkMinusSelfIsZero(x){
    return x-x == 0
}
checkMinusSelfIsZero(NaN)
checkMinusSelfIsZero(Infinity)

def checkMinusSelfIsZero(x):
    return x-x == 0

checkMinusSelfIsZero(nan)
checkMinusSelfIsZero(inf)

A value times zero equals zero

function checkTimesZero(x):
    return x * 0 == 0

checkTimesZero(NaN)
checkTimesZero(Infinity)

def checkTimesZero(x):
    return x * 0 == 0

checkTimesZero(nan)
checkTimesZero(inf)

These last two have an interesting side effect too. One would expect that 1 / (x-x) and 1 / (x * 0) to result in Infinity. However, when x is Infinity, they result in NaN. Don’t you feel dizzy yet?

Bonus fun fact!

Hey, while working on this article I found something interesting about square roots in Python. As I stated earlier, Python raises an exception if you try to compute the square root of a negative number. But Python implements complex numbers natively so if you use the power operator (**) instead, it returns a valid result!

>>> from math import sqrt
>>> sqrt(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error
>>> (-1) ** 0.5
(6.123233995736766e-17+1j)

The perfect result would have been (0+1j) but due to floating-point precision issues, instead of 0 you have a very, very small number. I hope you found it interesting too!

Conclusion

Semantically sound code is much less prone to errors and reduces the need to be constantly catching exceptions. I hope these examples have served as a reminder that we cannot neglect special numeric values or take for granted many seemingly intuitive properties that, if overlooked, can cause apparently correct code to exhibit undesired behavior.

This post is divided into two main parts. In the first one, I’m going to introduce mathematical objects and mathematical applications. It is programmer-oriented, but I assume some level of math knowledge. In the second part, I will tell my personal experience discovering and researching previous work on this same topic.

Note: In case you know it, the Wolfram Language may come to your mind while reading this post. It is probably the most powerful tool out there for programming mathematics, as it is the result of years of continuous work by a very talented team. However, I won’t talk about it here because even though it is more accessible than I thought at first, it imposes restrictions that I didn’t want to deal with. I was not going to expect my reader to do so if I didn’t, in the first place.

What are mathematical objects?

Anything we use to make math is a mathematical object. For example, numbers ($3$, $27$, $-80$, $3.15$, …), symbols ($+$, $-$, $=$, $\pi$, $\epsilon$, $\sqrt{}$, …) and variables ($x$, $y$, …). From simple mathematical objects, we can build other more complex, like operations ($3+5$, $2^x$, $A \cup B$ …), relationships ( $2 \lt 3$, $x \ne 10$, $1 = 1$ ) and even full theorems ( $\forall x, y \in \mathbb{N}, x<y \iff \exists z \in \mathbb{N}:x+z=y$ ).

Modern programming languages provide all kinds of interfaces to represent and manipulate mathematical objects. Numbers, for example, are present in any non-esoteric language you will stumble upon. But what about more complex objects?

Mathematical objects in programming languages

Mathematical objects as data structures

While mathematical objects are relatively abstract concepts, their implementation in a computer is directly related to data structures. Different languages define different native data structures, and each compiler/interpreter implements the operations on said data structures, determining the mathematical objects that can be manipulated by that programming language without additional programming.

I say “without additional programming” because, in the end, all programming languages (the Turing-complete ones) are equivalent. Since we live in the future, you will find that popular languages have libraries that implement anything you can think of.

Languages for mathematical applications

MatLab works natively with matrices and their operations. Do you want to work with matrices in Python? With NumPy, you can, but it will be a little bit harder than with MatLab. Do you want to work with matrices in C? You also can, but it will be harder than with Python.

This is just a crude case of how different languages handle better some mathematical objects. And while matrices are a relatively common thing to use in programming languages, other math concepts are not. Remember that we are talking about very different fields of mathematics. You would be surprised how cleaner or even faster can be a program written in less conventional languages like Haskell or Prolog, depending on the problem.

So imagine you need an application capable of handling a lot of different math concepts: arithmetic, algebra, logic, geometry… What are your options as a programmer?

• You can choose a single multi-purpose language, like Python, R or Julia, that have immense repositories of libraries of all sorts. You may find redundancies that you would need to contemplate and probably translate to common data structures. Also, some concepts might end up being difficult to use in an idiomatic, clean way. Or, on the contrary, to make them idiomatic, they turn out to be poorly optimized.

• You could use more than one language and glue them somehow or even embed one into another. This way, you could take advantage of the benefits of each. Have you ever wondered how powerful could be an application made with JavaScript + Python (PyScript) + Prolog (TauProlog)? That sounds like the third wave of AI to me! Just kidding, sounds very interesting but just reading it already gives me a headache.

• Another option is to turn your application into different distributed services. Collaboration is key to growth, isn’t it? What if we implemented specialized services for different math fields and tasks and then make them talk to each other? It has the advantages of both previous points. You have a modular architecture, you can reuse code and you can use different languages, the most suited for each task.

Distributed math applications

Shared formats as middleware

When you connect several applications, you need formats. We could let each application communicate the way it wanted and enable the main system to interpret every possible format, but that’s not scalable.

The Web is the best example of this. Everything you display on a webpage is HTML by convention. There are countless markup languages, document formats… but if you want something rendered in your browser, you better translate it to HTML. Look at Mathjax or KaTeX. We didn’t want to write mathematical equations directly in HTML, because LaTeX was better for that. So we made applications that translated it into HTML.

Formats for humans vs Semantic formats for machines

Standard formats are powerful. When machines are able to communicate, everything is better. But HTML and CSS, for example, are a special case for one reason: their final target are human eyes. An HTML page might be a complete mess, but if it renders into a human-readable page, it’s alright.

In fact, when we decided that we wanted the web to be machine-readable, the concept of the semantic web was born. Because machines do not care about presentation, they care about semantics: the meaningful information they can parse from the used formats.

Semantic math formats

And here’s the problem with a lot of formats for mathematical object representation; they are made to present information to humans, not to machines. LaTeX, for example, doesn’t hold much semantic information.

$xy + sin(e)$

The expression above is written in valid LaTeX, but it is pretty ambiguous. Is $xy$ a single variable, or the product of $x$ and $y$? Is $e$ the Euler constant or an independent variable? We don’t know, because LaTeX is not a semantic format. A human would know the answers thanks to the context in which we use the expression, but probably that context is not machine-readable.

Wikipedia points out three main formats for computer interchange: MathML, OpenMath and OMDoc. The people involved in the development of each one worked on the others too, so they are sort of complementary.

• MathML has two variants: Presentation MathML, which doesn’t hold semantic information, and Content MathML, which does. The mechanism for describing the semantics of its symbols is not present in the format itself. For that, it relies on the OpenMath standard (or similar alternatives).

• OpenMath provides two encodings to represent mathematical objects and also defines an extensible mechanism to describe the semantics of its symbols: the Content Dictionaries. There are official dictionaries that describe various symbols for different fields of mathematics, but any person or organization could define more dictionaries to extend the number of objects representable by the format. This way, an application that uses follows this standard only has to specify which dictionaries it supports.

• OMDoc, on the other hand, is some kind of extension to both MathML and OpenMath, designed to represent mathematical documents for humans and machines alike.

Note: I shouldn’t finish this section without mentioning the existence of SCSCP (Symbolic Computation Software Composability Protocol). It is a protocol developed to communicate distributed systems for mathematical computation, or CAS (Computer Algebra System). It is built on top of the OpenMath standard to describe a server-client communication oriented to mathematical objects.

My experience with the OpenMath standard

First encounter - Apparent death

OpenMath is the best suited standard to communicate distributed math applications.

I was really excited when I found this standard. As long as an application supported the OpenMath encoding (OM), it could be communicated with lots of other interesting applications easily, with a common format. A whole new world of possibilities for collaboration! I was sure I would find applications to transform OM into renderable formats like LaTeX or HTML, reduce or evaluate complex mathematical expressions, transform function definitions into code, etc.

However, disappointment came when I continued to research. Reading the openmath.org page I found a list of projects that used the standard. The first time I clicked on one: broken link. But, hey! the next link works! … and the linked project is obsolete; it has unresolved and unfindable dependencies. The official page is full of broken links and obsolete, incomplete and undocumented projects.

But it did not feel like abandonware from decades ago; there were things dated less than a few years ago. It was the same feeling as being late for a party that had just ended.

Finding the trail

I only found a Python library and a JS package implementing the standard, that seemed to be active to some extent… but neither of them contemplated the full specification.

The one in JS is a bit basic. And when I tried to use the Python one, I didn’t find it easy to do anything with it apart from parsing and serializing XML; it felt like the mathematical objects were not programmed to be manipulated easily. Of course, that can be (and probably is) my fault, because the library is used in another SCSCP library, where it proves to be useful.

At first, I didn’t give too much attention to the SCSCP library, because I thought it was not related to what I was looking for. I started my own Python implementation of the standard (if you visit it on my GitHub keep in mind it is very unstable and mostly experimental for now) and forgot about any official implementation.

However, I recently returned to that library, trying to understand it better with the knowledge acquired by working with OpenMath on my own. The SCSCP library caught my attention this time, and I followed one link after another until I understood what was going on. Part of these projects was recently funded by the EU in a program to foster the development of a European research infrastructure called OpenDreamKit that happened to finish in 2020. In fact, there are two more projects built on top of both the OpenMath and SCSCP Python libraries that belong to said infrastructure and seem to have little attention from other developers, even though they seem to be the only current functioning projects based on that technologies.

My interpretation

Disclaimer: I don’t talk on behalf of anyone except myself and I might have incomplete or wrong information about what’s been going with OpenMath on in the last decades.

I’ve spent many hours browsing the pages related to OpenMath and I’ve come to a conclusion. It looks like a lot of this work started long ago, in the nineties, which explains why there is so much that’s become obsolete (so it is in fact like abandonware from decades ago). To me, it looked like back then their work was more similar to projects of software development. But their society has always been closely related to universities and public funds (similar to the OpenDreamKit one). So their current available work is very academic! They have papers instead of documentation and research groups instead of communities.

They made their last workshop a year and a half ago (Jul 2021) so they were active recently… But then, why don’t they update their website to reflect the actual state of the project? Why isn’t there any work to integrate the standard into modern, popular frameworks used for mathematics? I’ve come to think that it’s just that, if they are actually still active, I’m out of the appropriate communication channels. I don’t know if I’m in an empty room or just in the wrong room.

Conclusion

Is the project just close to a death of disinterest? Or maybe the circles using and developing it are not the circles of software developers, but of researchers and academics? I honestly don’t know. But, also, I don’t care! I found the project to be fascinating and full of potential. The OM Society might not have the same philosophy as other modern open source projects, but their work is there for us to use it.

I think the idea of distributed mathematical systems is wonderful. But not only for researchers, who are the people using them right now; also for developers! My intention with this post was to make these concepts and possibilities known to people interested in working on open source projects like the ones we do know, in the hope that new, open and active communities can be formed.

If you liked this topic, let me know and I will write more about it! ✍🏻 I haven’t explained anything about the format, encodings and content dictionaries of the OpenMath standard, so I’ll probably write another post explaining how to use and implement them.

References

• https://www.omdoc.org/about/

• https://openmath.org/about/

• https://www.w3.org/TR/MathML3/

• Symbolic Computation Software Composability Protocol - SCSCP - Specification, Version 1.3

• OMDoc – An Open Markup Format for Mathematical Documents

• Interoperability in the OpenDreamKit project: the Math-in-the-Middle approach (3rd section)

It’s been more than two years since I began blogging. It all started with a development journal for one of my latest projects at the second half of 2020. I knew I wouldn’t be graduating that year, so I decided that I could try to gain some online presence to compensate my lack of professional experience.

https://dev.to/miguelmj/writing-a-conversational-user-interface-library-full-series-3dc5

DEV.to was in a boom, I was seeing a lot of developers start blogs here, so I decided to give it a try. I found the other platforms a bit intimidating, but this one was very approachable and beginner friendly. I wrote every week or two and found some interesting people to follow. I didn’t get much attention, but it didn’t matter! I was here for the experience of writing and the growth that comes along.

I wrote more than a development journal. I had a lot of opinions I had formed during my years in university and advice to give, so a lot of what I wrote at that moment was the kind of things I would’ve love to know as a freshman. It was a true pleasure to have a space to write it all down and share it.

https://dev.to/miguelmj/why-and-how-to-use-pen-and-paper-design-an-algorithm-11nn

Before the year ended, the DEV.to community did a lot of work around the moderation of the platform. At that time I was made a trusted member and to say that I found it rewarding, for the short time I had been here, is an understatement.

2021 - A comfortable plateau and the seed of dissatisfaction

With the new year, I slowed down my publication pace and started writing monthly. There was a lot going on in my life, so I felt comfortable with little activity; enough to continue the habit and keep my presence out there. You can tell it was a weird year for me because I have several unfinished series and a failed attempt to translate all my posts to Spanish (my native language).

Despite all this, it was a great year in terms of growing my personal brand. My open source projects started to thrive (I was even featured in an incipient newsletter, now dead) and I started writing for my current self, more than for my past self.

https://dev.to/miguelmj/data-structures-in-prolog-where-to-start-53gm

Also, a very strange episode happened that year.

I was invited to write a featured post for another platform. As it was my first post written for someone else, I wanted to make it about a popular topic: JavaScript, something I had never written about before.

Unfortunately, that site turned out to be a complete scam. Most of its content is stolen, their complete Q&A section is a literal scrap of the StackOverflow page and each and every user I interacted with was a bot (they even used watermarked stock photos as profile pics).

I got out of there as quickly as possible and published my article here in DEV.to. In less than 24 hours, it had more traffic than all my previous posts together. Today (January 2023) it is still my third most read post.

https://dev.to/miguelmj/take-full-advantage-of-high-order-functions-examples-in-javascript-4ibg

I remember reading several posts here talking about the spam, the clickbaity low-effort listicles, the daily copy-pasted git tutorials, etc. If you have been here for a while, you will know that the quality of the DEV.to content is still an unsolved issue. I didn’t fully care, I was comfortable here and that was all that mattered. As a trusted user, I did my best to mark low-quality posts and boost well written, original content.

However, dissatisfaction started to grow inside me, and a feeling that something was not fair here. Not only because of all my beloved posts eclipsed by my own single JavaScript tutorial, but also for the people I follow that publish interesting, advanced content, that get 1% of attention and feedback received by the mass of low quality posts focused on beginners.

2022 - Last year in DEV

The following year I did very little blogging. Most of my posts in 2022 were for promoting a project or another (looking back, I coded some interesting stuff). The two biggest exceptions were very significant posts to me.

https://dev.to/miguelmj/how-to-get-answers-on-stackoverflow-3pp7

This one came after I saw some people complaining about the StackOverflow community. I wanted to do an attempt on bringing closer two of the communities I love, from which beginners benefit specially. I expected some backslash in the comments (given the hate SO receives from some people) but instead I got a lot of comments from veteran devs, liking my post. It also gave more insight about who reads what.

https://dev.to/miguelmj/javascript-is-not-an-untyped-language-1jkg

And then, there’s this one. This one was an explosion. I know it was a controversial opinion on a perma-hot topic like JS, but damn, this post has five times as many views as my next most viewed post, and it’s my top reacted and commented post of all time. It got featured in the social networks of DEV, tweeted several times and even improperly published as material for an online course.

https://twitter.com/ThePracticalDev/status/1541501371962253314

And it was a rant written in a single afternoon! This is perfectly one of the posts I’ve put the least effort into. I stopped writing, discouraged. I know effort doesn’t correlate with impact when we talk about writing on the Internet. But I just didn’t like the idea of going back to write high effort posts for no one, always tempted to write about JavaScript again only for reads.

After some time, I was contacted yet by another platform, asking me to write a course for them. Another dev that had worked with them recommended me writing my own book, instead of just a course. Don’t get me wrong, that platform is legit and has great content; in fact, I tried to make the course they wanted. But I didn’t have enough time.

Writing an article for a blog is something, but writing a course or a book is another dimension. It is something I want to do, but I probably won’t anytime soon.

The big hiatus and the decision to move

It’s been months since I published anything. There are several things I want to write about, but these months have been very busy, plus I don’t feel like I have found my audience yet, which disencourages me even more. I don’t even read DEV anymore, as the content quality has only gone down, in spite of the efforts to implement tag filters and experience level for posts.

So, to find new motivation, I have decided to move on. I need to keep looking for an audience that I feel I connect with. I love DEV and everything I’ve achieved thanks to it, but I need to keep looking for a better space for my blog.

I’m going to try my luck with Hashnode. I don’t have any particular reason, so I don’t know if it will be my definitive platform. I want to see what kind of audience I can build there and explore the possibilities of a different tool.

Conclusion

https://miguelmj.hashnode.dev/

My first step has been to migrate there a curated list of my posts and polish them a bit. The canonical URLs will still point to the original posts, nonetheless. I will keep publishing in DEV everything, for the readers I already have here, but I will make Hashnode my main target.

I guess that, as a lifelong student and an eventual teacher I will always have something to write for beginners. However, I want to try a different level of writing and even different types of content. I don’t know how my blog might evolve, but, of course, that’s the exciting part!