Entry #3: The Hundred-Year Language

“The Hundred-Year Language” is an essay by Paul Graham, derived from a keynote talk at PyCon 2003. The essay explains why languages do not evolve as technology does, the author mentions that languages evolve slowly because they're not really technologies, as languages are notations. 

A program is a formal description of the problem you want to solve using a computer. The rate of evolution in programming languages is more like the rate of evolution in mathematical notation than transportation or communications, because, Mathematical notation does evolve, but not as technology does.

Paul Graham mentions that the fundamental operators are the most important factors in a language's long term survival so the rest of the language can be changed as it can be fixed later while operators don't. Also, many of the languages are written based on these fundamental operators. 

In order to have the hundred-year programming language is that we should not only see a good language only if it is good to program today but to also see how can this language can be good to program within a hundred years. We should not only care about the steps we are taking now but also we should care about a few steps ahead from us now.

In a hundred years, we cannot be sure what the programming languages ​​will be like, and the ones that will continue with the speed trends of the technology. We will solve problems that cost a lot in terms of processing and storage in less time than nowadays. By trying to reach efficiency, by imagining new design solutions and by proposing ideas that maybe someday will be possible. We can keep on wondering how the future will be, but it is useless if nowadays languages and people won’t adapt to this unpredictability as we figure it out.

Essay: Graham, P. (2003). The Hundred-Year Language. Recovered from http://www.paulgraham.com/hundred.html

Comentarios

Entradas populares de este blog

Entry #7: Building Server-Side Web Language Processors

Entry #4: Internals of GCC

Entry #2: Making Compiler Design Relevant for Students