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. 

7th program: HTTP Compiled

I’ve had the pleasure of using a web-oriented approach when I took the Programming Language Course last semester and I can say that it is a very interesting way of learning about different languages and paradigms while also looking at how to implement the characteristics and features that make them unique in web servers. While it is true that it adds a layer of complexity, most of the class took it as a challenge I think. It certainly is very interesting to think about asynchronous calls while also grasping the use of a functional knowledge such as Clojure. 

The use of web development that the author proposes allows for integration of knowledge while also practicing for a very important skill for professional use, that is, carrying a project through its entire lifecycle, whether it is by starting from scratch or taking an already started project like a kernel. When the aforementioned course was over, I was really impressed by what my classmates and I had created for “Semestre I”.  However, I think there is also a downside to this approach.

This comes in the form of compressing what could be several courses into one. A student might judge certain contents as not as important as others. For example, if a project deals specifically with the syllabus of web programming and some other minor activities for functional programming, he or she might brush those lectures to concentrate on what will give a better score by the end of the semester. Cases like this show the importance of combining all topics and show their relationships. 

A funny case of doing language processors through a server-side web application is how it can light a passion not seen in students since the first semesters of Computer Science/Engineering. When first learning to program, I was completely impressed and almost felt like a god when I created a small buggish version of the game snake.  That same feeling was a bit normalized as I spent more and more time programming. When I began working on the compiler project, I once again felt like that. After all, I was creating a program to create programs. It would be very interesting to see what the next level would be like.

I ran out of monikers for blog entries number6.cpp

I never had the chance to interact with something similar to the SIF when I took the Programming Language Course last semester. That’s a shame because it seems like a very interesting work tool that enables better comprehension about the way in which one may go about creating a new language or to better understand the basic mechanisms of the functional and imperative programming paradigm. What I also find interesting is how we can skip all the complexity of trying to create a new or feature from a low-level language like assembly or a really verbose one like C and just concentrate on what is really important, like data, semantic and syntax.

Another important aspect of the SIF, at least for me, is how it is based on such a simple pattern like Adapter and how powerful it can be. Even with an OO-Pattern and using and OO-Language we can create a something very similar to Lisp or functional languages in general. This makes me think about the theory of computability as proposed by the Church-Turing Thesis. Copeland (2017) describes any computable method with this hypothesis as one that can be done by a human with sufficient time, no intuition and only using and pencil and paper. This method must also be programmable in a Turing Machine, in the sense that the machine must approach the desired result using only instructions available on a Turing Machine. Since practically all computers in this day and age are Turing Machines with different implementations, we can represent any algorithm using any of those implementations. Meaning, we can compute pretty much everything using any kind of paradigm and represent anything starting from a particular paradigm and “translate” it to another.

I hope that when I work in the near future, I may be able to experiment with the tricks and interesting factors of many languages, maybe even help in creating one myself.

References:

Copeland, J. (2017). The Church-Turing Thesis. Stanford Encyclopedia of Philosophy. Recovered on 11/03/2019 from:  https://plato.stanford.edu/entries/church-turing/