Internals of GCC (Commentary)

 

I'm just gonna go ahead and try to write on what little I understood from the podcast.

The stages of program compiling have been taught to us thoroughly on this course, what we did not learn about, and I find the most interesting about the GCC, is its so-called middle-end. Compilers are no longer a thing of magic for me, but they are definitely a wonder in their complexity. I do not pretend to thoroughly understand the works of every and all software architectures, or their compiling mechanisms.

But, this middle-end actually solves an issue I've been having with compilers. How does interconnectivity between the programming language and machine language works? Now what this particular component does, is that it already receives a CLR version of the introduced code, produced by the front-end.

The middle-end in turn passes a machine language version of the CLR into the back-end.

This means that, while the front-end is language dependent, the middle-end is language and architecture independent, and the back-end is language independent and architecture dependent.

Language Design and Implementation using Ruby and the Interpreter Pattern (Commentary)

 

I remember during my Software Architecture Course (imparted by Professor Ariel Ortiz, who imparts Compilers Design, Programming Languages, and was also my current boss' teacher) we were assigned a task for the interpreter pattern. Basically, we had to create a DSL for s-expressions (or something that looked like them) using the Ruby language, which was, in itself, a titanic task. I'm grateful this particular pattern was not a part of the curricula for the final exam.

Now, while taking this Compiler Design course, I wish the whole affair could be done using Ruby.

While examining some of the topics pertaining Compiler Design, I can't help but wonder some details that are reminiscent of the Programming Languages course. For one, I find Bison's syntax to be similar to s-expressions, switching of course parentheses for brackets. It still seems to follow some of the same convensions, each statement or line to be evaluated is accessed as a list, and through its indexes, values located at a certain place are evaluated as specified in the rules.

Another excercise Professor Ariel seems to be quite fond, is processing operator-first syntax with a basis on regular old operations.

It is to be expected that lisp-like syntax would have its advantages in designing compilers, it offers easy recursion, and the fact that the operator is written first, makes everything simpler to be processed by reducing the number of grammar elements.

Technical Overview of the CLR (Commentary)

  

Gotta get this out of the way:

For Java to be such a recurssion heavy language, I find it hard to believe that tailcalls are not a priority for the Java Virtual Machine.

While the article is pretty relentless in its critique towards the JVM, what I find the most interesting is the actual meaning of the CLR instructions, particularily those used in imperative programming languages such as our very own Deep-Lingo. It's good to take a look at the most primitive elements of programming languages such as structs, value types, type refs, and what comprises integers and other primitives.

I still have troubles comprehending something that was said in my compiler's course. We were told that every value that can be used, written, modified, and defined in Deep-Lingo is actually an Int32 type. Sadly, although very iluminating on the nature of intermidiate languages, this article failed to help me resolve (or understand) the issues  I've been having with this idea.

Moving away from confussion, the article is pretty clear in its definition of the diferent stacks used by CLI to handle variables, values, parameters, and instructions. Not that this stage of compiling has become crystal clear for me, but this piece definitely sheds some (frankly, much needed) light on what's next.

So long, and thanks for all the books!

My first contact with Douglas Adams' work was through Netflix' Dirk Gently's Hollistic Detective  Agency series, based on a novel by Adams himself. It was love at first sight for me, the hilarious absurdity, strenous suspense and interesting character development heavily reminded me of Good Omens by Terry Pratchet and Neil Geiman, a very brittish book about the Apocalypse, kids, music, religion, space, Atlantis, witchcraft, and friendship.Right off the bat, the general feel of the series seemed to be tailor-made for my taste in humor. 

I had already purchased both The Hitchhiker's Guide to the Galaxy and The Restaurant at the End of the Universe, but hadn't had the time to read them. I was very excited to actually open these books back in January because I would finally look at Adams' magnus opus and the start of it all.

And it didn't fail to impress.

I wasn't really expecting such a complex space epic, my idea of this book was that of a brittish joke fest, but the interesting characters, space lore, and background made it quite the treat to read. The language used to describe abstract events is also pretty impressive and a very strong quality in the first book, Adams has quite the way with words and can make everything sound relatable and understandable.

Even if the book shouldn't be taken in a serious note, some things seem to be written in order to move or impress the reader such as the description of the coastline factory in Magrathea. He can create a sense of wonder in the reader with spectacular descriptions blown out of proportion, and make them laugh in the small details that decorate every single dialogue.

What's also noteworthy is the cultural impact this series has had, specially in the field of computer science. Most language tutorials use 42 (which is the meaning of Life, the Universe, and everything) for their numerical examples, and Marvin is one of the most recognisable robots in sci-fi history, even if people haven't seen the movie. Not to even mention the rampant jokes about the Babel Fish.

There's a lot that could be said about Mr. Adams, but, quite frankly, as of now, I'd rather keep learning myself by reading his work, than talk straight out of the Wikipedia article.

So long, and thanks for all the reads!

Building Server-Side Web Language Processors (Commentary)

 

When talking about web programming and same ol' regular software programming, there are a lot of details to take into account. It is only natural to think that same principle applies when talking about the compilers and their attributes for each of these particular jobs. 

First of all, web applications are significantly more vulnerable to security attacks, particularily those involving string management. Cross-site scripting, and SQL injections were big names back in the day before people thought about removing certain characters from inputs, or blocking them entirely. Even though some of these problems could be perfectly dealt with in the development stage, developers won't make a mistake we don't allow them to make form the start.

Then there's the matter of the Web itself. Server, clients, and requests are central elementes of Web application development. A compiler for web-focused languages should be fundamentally concerned with the management of these three aspects, specially when they are being created for the server side of the equation. 

Last, but not least (though, a bit periferal) is modularity. A web-based compiler should be light enough to be inserted in markup language templates (HTML based pages,  XML documents, etc.), either as a series of tags, or even as a single tag. This could also mean that our web-based compiler could work alongside already established, widely used net frameworks.

Mother of Compilers

"Margaret Hamilton", "Ada Lovelace", "Joan Clarke", and "Carol Shaw". All well known names of women who gave it their all to make Computer Science as a field what it is today. Be it religion or politics, one of the most common phrases we hear by detractors or followers is "What has Jesus/God/President Trump/Obama done for you?", and so, in terms of which of these women have done the most for me as a software developer, I must say, none of them come even close to Grace Hopper.

Ignoring her fight for recognition among a male dominated field (which is largely admirable in its own right and shouldn't be ignored outside of the context of this particular blog entry), Hopper had a mind set in the future, demonstrated by her programming technique stemming from Basketball's "forward throw", and her willingless to ligitimize "silly ideas" such as speaking to a computer in a clear human-like language. 

As a student who started his career in the early 21st century (in the first decade, to be precise) I cannot work out the functioning of perforated cards as a legitimate programming device. For me, programming has always been about bright instructions in english on a dark background, and it has always made sense, in a very concrete way (even though abstraction is one of the core principles of programming).  The fact that I am able to write letters into the processor (which in no other context mean anything at all) and receive an actual response is one of the reasons I used to believe compilers worked on magic.

And perhaps they do, perhaps they are a manic concoction from the ancient magics of "symbology" and "mathematics", concocted by a witch called Grace Hopper, aided by a visionary instinct and (perhaps) a dash of madness.

The Hundred-Year Language (Commentary)

It is mind-bending to think about the immediate future of modern computer, forget about what's going to happen in a hundred years. I, for one, hope there's still a humanity left to ask this questions in, say, 50 years. For the meanwhile, let's just imagine we are not under constant threat of an all-out nuclear war. 

One of the main points of the article which I find particularily interesting is the need for clutter in a language's process of evolution. Numeric types being an example for LISP's dreadful, despicable, and messy transformation into Clojure. Clutter is wasteful, but it has a reason for existence, even if it's not totally useful at first.

Another important concept mentioned is the fact that Moore's Law is bound to stagnate by its very nature, which means programmers and hardware designers alike need to work around the problems arousing from this process. This event is one of the cornerstone reasons for the development of a universal programming language that shall endure the test of time. Considering the different elements involved in Language Evolution (clutter, necessity, data types, etc.) this process may prove to be chaotic. If we add the fact that we don't know how the future (or its hardware) looks like, the creation of a universal hundred-year language seems near impossible.

As many a developer of Silicon Valley hopes, whatever the outcome, it better make the world a better place.