Technical Overview of the CLR

Technical Overview of the CLR

the article Technical Overview of the Common Language Runtime by Erik Meijer and Jim Miller, is a comparison between JVM (Java Virtual Machine) and CLI (Command Line Interface).

The main difference is that the CLI is a platform that supports a big range of languages.

About the JVM, is usual to think that it is only a runtime environment for Java programs, but as an example of the opposite, some variants of LISP uses JVM for its execution.

Some of the important consideratios with  implementation of alternative paths for native compilers are:

Portability: This is, using an intermediate language you need n + m translators instead of n * m translators (n languages in m platforms).

Compactness: Intermediate code is more compact than the original source.

Efficiency: you can adapt the dynamic behavior of the program delaying the commitment to a specific native platform.

Security: Intermediate code is more amenable to deploy.

Interoperability:  sharing a common type system and high-level execution environment,  becomes easier than binary interoperability.

Flexibility: Combining high level intermediate code with metadata enables some features like: dynamic code generation.

Some of the points in the article about CLI and JVM:

*JVM does not provide encoding type-unsafe

* In the JVM all storage locations are 4 bytes wide

* In the CLI, storage locations are polymorphic, this means that the wide could be 4 bytes or longer.

*In the CLI the generic types can readjust the value size according with the current processor.

*JVM is that it does not indicate overflow during operations on integer data types

* CLI provides built-in support for boxing and unboxing, it means, a value can be turned into reference type object and viceversa.

Well, both have features that make them usefull but, mostly depends of the kind of language to implement, so is convenient to be consent of what the language needs to perform.

Building Server-Side Web Language Processors

Building Server-Side Web Language Processors

OK … I can undestand why but honestly i do not like web development. That is fun because I prefer using web applications than real apps stored in my hard drive. (why every service needs an app? It has no sense).

But it has sense, nowdays is required for all the entrprices to have a web page and some of the requirements for (lots of) jobs  are web experience or web development skills. One of my partners is a little bit obsessed about web design and development, I am sure hi will be In total agreement with the article.

However, even if the purpose is the same (compilers here, compilers there) in web the expecting result is an HTML page but (opposite of my sister thought, she is not well informed about, not her fault) it is not most easy than grite a local version of the same language processor. It is necesary to transform the input to one with delimitator used to pull apart the static code used for the output and the code that will be calculated and finally  to something usable for the browser.

I like the idea of having specific conventios for variables. But honestly i think it could not be the best idea, even if you write abot if another developer needs to check the performance of the compiler/ interpreter it is posible to have nonsense or to be complicated to adapt.

I did not have idea of how to use customized tags for specif language web implementation, but it sound like an usefull tool. Now (I think I undesrtand a little more how it works), It requires a Tag Library Descriptor file, a XML file, which needs to contain information of the library and the tags it contains.

I have a confuse opinion of the article, I half agree about the interest to meke something in a web version because “instead of a processor that just runs on a command-line shell.”it is more interesting fore most of students but if it was the case for me it will be like hell. (my fault, not the proyect´s but… )

Ruby and the Interpreter Pattern

Ruby and the Interpreter Pattern

For this time the article that we had to read talks about an interpreter Framework developed by our professor Ariel Ortiz using the Ruby language.

I have use the language before but just for some few ideas and quick aritmethic operations. In my opinion it is a friendly and nice language. I'd like to investigate more about but i have a mess of programming languages in my head right now … maybe soon.

I remember that everything in Ruby is an object (I forgot it but then, when i was reading it comes to me), including: strings, numbers, arrays (lists), hashes (maps or dictionaries), symbols, procedures (closures), and even classes.

Going back to the article,first, why 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.

The article is mainly about the S-expression Interpreter Framework (SIF), In general way a S-expressions are a parenthesized prefix notation, mainly used in the Lisp family languages because it's origin lies within the Lisp family of programming languages whose entire syntax consists of those expressions.

Is also mentioned the article “The S-expression Interpreter Framework (SIF) provides the basic building blocks that allow writing interpreters that can easily be studied, extended and modified”, it is actually really useful and can be used in  various ways in language design or/ and implementation.

In my experience the Lisp descendants are at the beginning hard to learn but with practice the lines are less and has lots of easy ways to do the same actions with less problems. 

Reading a little more explains that SIF implementation was made to define languages using this notation easily (not for me but in general cases), but it also can be used to define other programming styles like imperative or object oriented.

Reading it was really interesting and it explains some doubts i had.