The Hundred-Year Language Commentary

In the essay " The Hundred-Year Language", adapted from a 2003 keynote by Paul Graham, the hypothetical idea of a programming language that will be used 100 years from now (almost 85 years from now, actually) is discussed. Concepts such as programming languages evolving and some being left out, either for not being optimal or eventually phaing out, and one of them "evolving" into the language of the future.

The idea is interesting, given that it is true that over the years some languages have been abandoned in the dreaded realm only known as "legacy code", and yet I find it a little bit hard to see the future of computing moving in such direction. Graham hopes and reasons that computing power will be so powerful in the future, that programmers won't have to worry about algorithms that are fully optimized, since resources are so vast. However, I am not completely sure that we'll be using the same kind of computers in 100 (more like 85 since the keynote) years. I do believe that Moore's Law is at its last legs, and soon technology will be forced in another direction. Quantum computing has been and attractive alternative, but even before 2003 physicists and computer scientists thought we would have something more tangible in that area by now.

First image related to "quantum computing". As abstract and hard to picture as the real thing.

EIther way, and regardless of the slow advancement in such areas, I do believe programming as we use it and view it now will change drastically. It certainly should be if we hope to find a way to try and solve those NP problems, since it seems our current method is rather slow. The hundred year language might not even be what we understand and define today as a programming language to begin with, but it hasn't changed that much either in the 14 years from the keynote, so who can really tell? Lets just hope the language of the future isn't harder than making compilers.

Source:

Graham, P. 2003. "The Hundred-Year Language". Author. Retrieved January 28th from: http://paulgraham.com/hundred.html 

Making Compiler Design Relevant for Students who will (Most Likely) Never Design a Compiler*

In the artcile "Making Compiler Design Relevant for Students who will (Most Likely) Never Design a Compiler" written by Saumya Debray in 2002, describes reasons why even when most Computer Science students don't end up working on compiler design, it's  useful skill to have. Additionally, the steps a compiler executes are described and many example of similar problems are mentioned. The main argument being that compilers can be seen as translators, and the techniques used to compile a program are techniques that can be used to translate any set of other elements, not only text.

And so, the value of learning compiler design is more evident. It is true that personally I have never considered compiler design as a big part of my future, but is is gratifying to know the knowledge of such a course can be applied in other creative ways. One wouldn't imagine translating text to a graph would use methods used in compiler design. In a way, it could also be understood that a student's reluctance may reside on the fear of machine language, but when that aspect is removed, the task seems more like a tool and less like a chore to be learned.

A line used by the author is particularly interesting: "students often seem to compartmentalize their knowledge". After some thought, it rings true. Maybe it's the lack of multi subject tasks that can be assigned to a student in such short time, but the fact that each subject is taken as separate from all the other can hurt the expectations of certain topics. 

Compartmentalized doves. They should work together, but it's easier to picture them separately...right? 

Thus, it can be harmful to ignore the skills learned in different subjects or areas just because they are heavily related to one specific process. It's not evident at first glance that translation algorithms use some techniques used by compilers, or that you can easily take a database language and change it to another by using token analysis. In the end, the knowledge is always valuable, and it should not be dismissed by the classic student question "How will this be useful to me?"

Source:

Debray, S. 2002. "Making Compiler Design Relevant for Students who will (Most Likely) Never Design a Compiler". University of Arizona. Consulted January 21st 2017 in: http://webcem01.cem.itesm.mx:8005/s201711/tc3048/making_compiler_design_relevant_for_students.pdf 

Yael Araizaga's Course Introduction in Compiler Design

Huzzah my brethren, tis' that time again. Time for another blog dedicated to discussing and commenting topics related to technology and other "arcane sorcery". This time compiler and medieval themed.

Through the reading of books and ancients texts, I expect to learn about the inner works of translating languages into the lost and mystic tongue known as "machine language". A daunting task indeed, worthy of only the greatest of warriors. The road ahead might be perilous, but I'm certain the knowledge obtained through these years will prove useful, and this course will allow for the elevation of that knowledge.

On a personal note, my hobbies include the following: hoisting heavy weights (AKA lifting weights), reading graphic novels, playing videogames, enjoying both TV shows and movies of all kinds, and recently, playing Dungeons and Dragons.

Let's hope dragon slaying in DnD is similar to tackling compiler design....

In my minimal spare time I have dabbled with reading a few Lovecraft stories, the Swoly Bible (of course), as well as viewing all recent Marvel Studios content, tuning into HBO's Westworld while GoT returns, and playing far too many games to count. That might change though, as dragon slaying seems to be a 24/7 task. Time will tell.

My best wishes to all other knights in this journey, may your combat rolls be mostly critical and fumbles on meaningless checks.