The Hundred-Year Language

For me, this article seemed extremely repetitive for the things that it wanted to express, just giving more and more "examples" and over explaining the same concepts one, two or even three times, not only making it really slow, but also having us reading about how would the 100 years language would be, with the same 2 declarations. The future's language will have less "waste of time" for the programmers, and will have the least axioms for the basis of this language.

One of the most interesting topics that are treated is for the programming languages not been able to evolve at the same rate that the general technology are doing. This makes a little more easy to explore the possibilities for the future 100 years, but have the issues that are described, like to not knowing if even the programming languages will still exist then. Even considering the complexity of this labor, the basis that this article takes for concluding that the way of programming it's actually developing around the inefficiency but giving the programmers more tools and flexibility at the time of programming.

An interesting point made and that I thought that could be relatable to the third and fourth generation of programming languages is the concept of not having this rigidity at the data structures, but having the best performance available. As stated by the author, the computers are becoming more powerful every year, and it's a fact that this won't change at least in the near future, and even when this opens the door for more waste, as is said into the article, also I think that that will give us the opportunity to get every time more memory and performance dependent problems to get solved, and with this in mind, not to marry us with the idea of having simplified languages, but to take advantage of the "more complex" languages and get all the potential for the programing to shine at it's best.

Comentarios

Entradas más populares de este blog

Introduction

Making Compiler Design Relevant for Students who will (most likely) Never Design a Compiler