8th program: CLR.jar

While reading this paper, I must admit that I had trouble understanding most of the intermediate codes and all of the different types and instructions available for the CLI. It seems like a mix between several different languages, where I may recognize some things about syntax or indentation from Java or C# and the instructions would seem like they were made for a very intelligent assembly language compiler. I guess that this is the goal of creating an intermediate language and my confusion arises from the fact that I had never worked with the insides of such compilers/architecture such as the JVM. When I first heard of this, I thought that the IC would be a lot closer to the assembly language, but just made for an “abstract machine”. I am happy that my suspicions were wrong.

I really like the idea of using an intermediate platform from where we can talk to any machine we like from any language we fancy by just creating translators for said machine. This obviously results in a lot less specific implementations, which is very good for all developers in general. This implies 2 things: One, designing such an environment was a probably a lot harder than most implementations for specific technologies; Two, this opens up a new market in which compiler artists and language designers can work, generating work for new machines or aiming for portability and compatibility for older languages or technologies.

One thing that is predominant throughout the article is the author’s significant predilection for the CLR over the JVM. I’ve never had the pleasure (or suffering) of working with said platform, but I think the authors can be a bit unfair regarding certain aspects of it. The JVM was made In a time when creating intermediate byte code was a rare event and a lot of people were concentrating more on its freshness rather than how it may evolve, at least that is what I think.