A bit of the story: Mélodium takes its roots from signal analysis studies in Université du Québec à Montréal (UQÀM). A need for tool allowing massive audio analysis while using very low-level routines guided the design of a “first” Mélodium version. At that time it was closest to a simple configuration language interpreted by a more-or-less generic engine, and presented in this thesis (in French).
While really technically oriented and very specific in its purpose, it made a very first step towards the idea that managing streams is a key-problem solving approach to many computing designs. At the same time, experiences coded with it had to run on very different machines, including some local computers with different OSes, and two supercomputers with different architectures; all of this with hardware from different decades. So comes the problem to make a high-level and generic stream manipulation language that goes down as directly as possible to low-level machine code.
The point was not to support this, then this, then that system or architecture; but to design something that is, by nature, portable to any realistic hardware and software host, with the less friction and custom adaptations possible. In other words, to break the complexity layers and remove useless abstractions from the developer vision to the machine mechanisms. To design with anticipation that systems can have only one up to thousands of cores, can manage operations on different kind of base units, can have execution frequencies that differs by orders of magnitude, that they basically meet a purpose and exist as they are.
This guided the development approach for Mélodium. To never consider it runs on “ideal” systems, but on very limited ones as well as unusuals. This enabled a very strong effect that is similar to web accessibility or real world inclusivity: by designing things without assuming system ability, it makes it better for all the others too.