Technical Overview of the Common Language Runtime

Now, on this entry we're gonna talk about the opinion of Meijer and Miller, about why JVM is not a good option for execution environment and it is just a suboptimal multi-language platform. To make a clear analysis of this, the authors compare between JVM and the new Microsoft .NET CLI (Common Language Infrastructure), that for the authors CLI is a better multi language execution environment than JVM. Because of the next reasons:

• It has as target multiple languages, in contrast JVM has as main target Java

• Managed multiple threads of control. CLI storage location are polymorphic, that means that there are 4 bytes or hundred of bytes. In contrast JVM are 4 bytes wide.

• CLI type system support a set of primitive types such as: object, bool, int8, float32, typed referece, etc. And as a main advantage over JVM, is the fact of the natural-size, these means that in JVM values of type long or double occupy to locations making difficult for compilers writers. Supports also classes, interfaces, arrays, delegates

• Besides CLI has polymorphic locations, it has also a little more polymorphic instructions (useful for compilers to generate MSIL code)

• CLI support tailcalls and JVM not.

• CLR provides built-in support for boxing and unboxing

According to the previous point, we can see that CLI has a better future that JVM, just because of the simple fact that it is easier to use for compiler writers. From my point of view for being a good execution environment we need to focus on the points, that at the beginning the authors mention, about why people look for an alternative implementation paths for native compilers that are portability, compactness, efficiency, security, interoperability and flexibility. Even though CLI seems to be the powerful and perfect one, they keep it making changes to be updated to the future necessities.

Ruby and the Interpreter Pattern

On this entry we are going to talk about an article wrote by our professor Ariel Ortiz, which for me seems to be very interesting, so here we go. The main idea of this article is talk about a framework called S-expression Interpreter Framework (SIF), because is a tool that the author have been working with the alumni of the Tecnológico de Monterrey specially in the programming language course. Before we continue, it is important to know that this framework is written in Ruby, but what is Ruby?
Ruby is an interpreted, dynamically typed programming language, that helps simplifying the construction on languages interpreters, more specific it has the advantages of having garbage collection, open classes, first class continuations, built-in regular expressions and hashes.
About the source language notation used was the S-expression (symbolic expression) mentioned before, is a notation mainly used in Lisp and the advantages of this notation are that code and data can be easily represented, minimal elements, no associativity problem. On my experience using this notation is that at the begging is hard because of the parenthesis, but once you get it, you notice that it is less code than in other languages. In the other hand, the interpreter pattern helps to evaluate a language grammar or expression.
These three S-expression, Ruby and Interpreter Patter for their use, the article give us a detail instructions taking in count that Interpreter.eval class method is the heart of the SIF and it supports integers, symbols, lists and procedures.
In conclusion, this framework is really useful (SIF) because of the features of Ruby give us and the interpreter. Ruby at the same time, it is important to know the bases of this programming language like data types, naming conventions and code blocks. Don't forget that SIF also can be extended.

Compile-Time Metaprogramming

On this entry we're going to talk about Compile-Time Metaprogramming with the help of Lauren Tratt, creator and inventor basically of the Converge programming language also he is a researcher at an University in London. To get started, the podcast talked about DSL from the guest point of view, but making a contrast with Paul. A DSL should be an abstraction relevant to specific domain, in other words you take a particular problem and you take it to the upper level, there is something important here for the programmer and is that is you are using DSL, you need to make easy to read and maintain that, because if you leave it for a long period of time you might have forgot what you was doing. Another point the author touch is the reason you want to embedded things in a host language is that maybe the language itself could make for us the translation, an example of this can be expressions.

The particular topic I was interested is knowing about Converge, because I've never heard of it, but it seems to support Macro System and DLS. So according the inventor of it, Converge is a new language alike Python at the beginning, the it have this compile metaprogramming stuff, that basically means is a Macro System and a Macro the thing it has is that is very heavy influenced by Haskell and you need to be able to built a decent AST (Abstract Syntax Three). 

In conclusion this is  session about language design, focused of Domain Specific Languages (DSL) and this new language named Converge created by the same guest and once again we can see the advantages with Ruby, that at the guest mention is a great tool to make DLS, because is dynamic and with friendly syntax and the most important it make easier for compiler writers.