|Social aspects of MLRISC
||[May. 21st, 2018|10:38 pm]
Social factors determine programming landscape no less than technical ones. Ideas, “technologies,” or programs enjoy different popularity even if they have equal technical merits. I think this may be a fruitful field of study for social scientists. PHP is a good example. How has the shitty programming language PHP become so popular? There are many technically better programming languages (PLs). So this phenomenon has to be explained by social factors. (And I actually think that the obscene word is a correct scientific term in this context.)
Popular explanations of popularity in information technologies use such terms as “dead” and “alive,” for example, “dead project,” “dead PL.” I believe that we should refrain from these biological terms; they really convey nothing. Ideas, specifications, and programs are not living organisms. They have no metabolism. They can’t die because they were not alive in the first place. So we need to focus on people.
Here I consider a case where social factors lie on the surface, and you don’t need to be a social scientist to see them. The case is MLRISC. MLRISC is a library for compiler back-ends which is written in Standard ML. It is used in several Standard ML projects. It is unpopular, and the reasons for this are discussed below.
MLRISC is not popular not because of lack of demand. Its economic background is sound. MLRISC provides a common intermediate PL for compilation. It is less work to translate high-level PLs into an intermediate PL and the intermediate PL into machine code for each processor than to translate every high-level PL into every processor’s machine code. This is already explained in the documentation for MLRISC. LLVM (Low Level Virtual Machine) serves the same purpose and is popular.
The first reason of unpopularity is the state of documentation for MLRISC. The documentation is scarce and outdated. I needed to fix its LaTeX source before reading because diagrams were missing. Okay, as a middle-aged Linuxoid, I do not mind this. Research papers are no documentation: they convey only ideas. There are no learning materials and no people you can ask. There are comments in the source code, but, obviously, they are not enough. Probably this is because of stimuli? Researchers are paid for papers and are not paid for technical documentation and teaching.
In a frantic effort to gather information I tried to subscribe to the SML/NJ mailing list. (The source code of SML/NJ contains MLRISC.) Only the email of the mailing list is advertised on the website for SML/NJ. How am I supposed to subscribe to it? But I am not stupid. I opened the list of mailing lists of the Department of Computer Science of the University of Chicago. The SML/NJ mailing list is not there. I took an URL of one of mailing lists and fixed it, and here is the page of the SML/NJ mailing list. Eventually, I sent a request, and the moderator accepted me. Looks like spy games.
SML/NJ is not the only project that contains MLRISC. MLton and Manticore contain their own incompatible versions of MLRISC. Splitting an already small user base among forks is the way to diminish it further.
Conclusion. Pinning down these reasons was easy. But they lie on the surface. What about reasons of these reasons? They will enable us to predict useless efforts before they even begin.