Common Language Runtime

This article compares the runtime environment of two languages that seem to be similar Java and C#. As far as I know, both are designed to be object oriented languages. For almost every semester at the Tecnológico de Monterrey, I have worked quite a bit with Java, I did use lots of the libraries from JVM, but I wasn´t aware of its limitations. As of now, I have not been assigned with a task that is complicated enough to require the low level interactions such as pointers or memory management in the professional area. However I did understand the usefulness of such and it did ring a bell about the possible limitations for library development. The article seems to emphasizes that it has limitations on pretty much everything compared to .NET's CLI. 

The way JVM builds data groups, analyses the syntax directly and them validates it as a new object before creating the datatype sounds extremely resource consuming. In the same way the author explains that certain programming paradigms are not possible due to the way JVM is built. Things that seem to be attached to the mathematical nature of a programming language such as recursion has to be implemented artificially when developing a compiler on JVM. Oracle did go a bit too far on their "we only compile proper code" adding too much overhead to their  environments. 

Well it seems the author is completely convinced that CLI is superior to JVM. As far as the course goes, I don't have any complaints towards the tools that we have been using in the .NET framework. C# has some hip tricks that seem to make writing the compiler considerably easier.  It is interesting that at this point, I start to have a better understanding of why did so many highly regarded professors and Stackoverflow users feel some kind of adversity towards Java. 

Implementing a web Language

I have some experience developing on server-side web applications. Back in my old job at AstraZeneca I had the task of giving security maintenance and updates to a discounts application, this was mainly done through a Node-JS middleware that communicated with the real back-end technology which was mostly implemented in the framework Spring for Java.
I was quite impressed by how different the paradigm is as it was my first time messing around with a "scripting" language. As the lecture states, the Node/Express framework is heavily focused on handling outer requests, perhaps  doing some processing to it and forwarding it. And I feel like implementing a lighter language with these specifications is more compĺex than developing a full scale console based language. One of my tasks was also implementing cross-framing with another of AZ's web applications. There is so much to consider in the security side for this type of languages. Cross-site scripting , click-jacking, header validations, watching for HTML injections among many others.

I think it was a good decision to provide a kernel to the students as it seems that dealing with HTTP requests at low level seems difficult enough that I can't imagine how do you even setup and test the most basic functionalities for this. It would be necessary to have some advances knowledge of the required web protocols I believe. Perhaps a project which focuses specifically on building a request framework for a secondary language would be as interesting and could have an insight into this obscure (for me) knowledge.

As tough of a task as it is, it sounds like something quite interesting and worth having a look at, specially at this point of time where a lot of companies are basing their desktop client applications on top of a web application, there are even some frameworks for this such as Microsoft's Electron which I believe is having a modest success. As much as I despise looking at some <a><{user.song}></a> bug on my Spotify desktop client, it seems that the experience that this project can potentially provide is proving to be more and more relevant in the IT industry.

S-Form Interpreter

Back in the day I was having fun with Scheme Lisp for my programming languages course, I came to wonder the reason for which whoever designed the language decided to make function calls in such an odd way. In this reading I just learned that the odd way is actually called S-Expression and it seems to be that way because it is easier to implement for the language developers. After many headaches caused by the ridiculous amount of parentheses in the nested functions of my final project, I gained adversity towards whoever designed Lisp. At that time I thought it might had to do with the recursive nature of the language. 

It seems that I was right in some way since the S-Expressions come naturally at the moment of applying recursion correctly for nested functions since the parser reads relying on the context defined in Ruby as it is shown in section 2.3.

Managing contexts seems to be one of the most useful implementations within the framework, having a quick access to data outside of the function being currently parsed seems to be something that is very characteristic of Lisp-like languages. In the article it is stated that the framework is quite able to support simple functional languages using the basic functionalities such as defining, passing arguments and setting functions. 

This article gave me a better understanding on why is it that S-Expressions makes parsing simpler. It is easy to see that on the Ruby code one can parse through the expression taking the first argument of the S-Expression (that is the function)  and defining what to do with each of the remaining arguments treating them as simple indexes of the obtained regular expression. Things get complicated when dealing with recursion and scopes, and as the author states, there are some basic optimizations for recursion that cannot be implemented with the chosen approach.

Grace Hopper: The Queen of Code

I believe that my knowledge on the history of computing is somehow limited at this moment of my life. Perhaps it is because most of the recent developments in computer science were achieved by the employees of corporations which makes the history of it slightly dull or hidden. However there is always somebody that is outstanding enough to spice up the history of things. I am very impressed that a woman achieved to come out as one of the pioneers of this discipline. If women in the IT sector have it quite hard nowadays imagine being a Navy officer and a computer engineer. In the middle of WWII. Perhaps, it was the war that forced officers and engineers to look the other way and leave behind their beliefs towards the role of women in the western society of the 20th century.

I do agree with the article in which states that somebody who designed the compiler had the ability to think ahead of the capabilities of machines for calculation. Naturally, somebody who had such importance so early in the development of computer systems, would create some myths around them such as the one of the moth. I find this myth to be quite amusing.

I believe the engineering world needs to encourage women to get involved as their contributions are so important they could enable a whole age-changing industry and science. Grace is a great example of strength and determination against all odds.