xmos / xc

I work on a software project that helps make an interesting, parallel language with a long history run on lots of tiny computers. More details can be found online.

Specifically, we run code that used to run on a processor called the Transputer. It was developed by a company called INMOS. Today, there is a company called XMOS, and it has some of the same people involved who used to be involved in INMOS. However, the world is a different place today, and I think XMOS is the right idea at the right time for a lot of very interesting applications.

In this forum post, one of the XMOS peeps a member of the XMOS community was wondering aloud about the state of their language, XC the native language of the XCore line, XC. They have realized at XMOS that more people now use their tools externally than internally. (This is a very good thing… users kinda matter.) So, a few questions were asked. I quote:

1) Releasing the current roadmap for XC – showing bugs, features and plans for future development with some timescales. This will enable developers – customers – to feedback on what is important to them and also plan for future improvements to the language. In particular, any plans for typed channels or protocols, process mobility, relocatable, dynamically-loaded code and modules (a reserved word), are very important to members of this community, as recent discussions have shown.

2) Releasing the current implementation of XC – the compiler and tools – so that the community can develop, improve, and learn from the implementation and the language, as well as be equally invested in its future.

Regarding number one: a language will not survive without community. And, while a community will invest in what it cannot control (eg. Twitter), this is a different kind of community. For XC to grow and be useful as a language, the users must have input. This does not mean that language design decisions should be made by people who have no idea how to design languages—but, that said, the people who use the language know what would, and would not, be useful to them.

Regarding number two: there is no doubt that the compiler should be open source. It is one thing to invest in a hardware platform that is closed: we do that every day. But I do not want to build software with tools that might be taken away from me at any time, or modified in ways that destroy my business. If I buy an XS1-L1, I want to know that code written with compiler version 1.3.2 will be able to be built and compiled for the rest of time. I want the option of never updating the compiler, if I need to.

But, more importantly, an open compiler framework would make it much easier to port occam-pi to the XMOS platform. Again, though… I have no desire to do work on a platform that is locked away from me. If XMOS were to move their compiler into a git repository, I could check it out, explore, and contribute.

There is no universe in which opening the compiler can damage XMOS. If their language is ported to another hardware platform, it means more people using XC—meaning, more potential users of their hardware. If new languages are ported to the XC, it means more potential users of their hardware. If someone decides XC is ugly, and designs a new front-end that is friendlier and more expressive, it means more potential users of their hardware. Have I made my point?

Compilers should be open. Period.

Updated 20100623: See comments for reason.