Hundred-Year Language

 

The hundred-year language was a really nice thought experiment highlighting some trends in modern programming languages and how the axioms of a language should be written. Probably the most impactful part of the article was when the author assures us that most of the extra cycles of a future computer will be wasted, it even made me laugh cause it most certainly will be a correct prediction. In the whole career I have never been told not to waste bits in my programs, only once I had been told to not waste memory and that was in high school while programming a microcontroller in C for a counter circuit. Indeed I was beginning to think of it as wasteful until he raised the point where it is most outrageous to waste programmer time, than computer time as in my little experience of having to work with limited resources, it does add things you have to be mindful of while programming. The reading even made me laugh when the author dissed pearl and object-oriented programming although I do not have experience in pearl nor writing code in a business to confirm if his claims are true. Also he ends with a really interesting point about how we could in principle write the hundred year language today, although we would be lacking the trial and error that we as programmers would obtain in a hundred years, or we could miss some kind of problem or requirement that just isn’t here yet. I know he sees the hundred year language as only a guide for the new languages and know we won’t get there any time soon. Overall, it was a good thought experiment whose answer we may not be able to see nor program in, but we may experience the steps in between.

Comentarios

Publicar un comentario

Entradas populares de este blog

Internals of GCC

In the podcast when Morgan Deters speaks about the internals of the GCC compiler it was interesting to note how the compiler compiles itself first using the C language to compile like a basic version of itself and then using that basic version compiles the full version, so that it does not assumes that the system has features of libraries that it needs, after the classes on the tombstones diagrams this makes sense and seems like a smart solution. Also building the whole front end without classes to avoid relying on features a system does not have is a really nice solution. I haven’t asked myself how they implemented in a compiler features that the language did not support and seeing that they use “cheap tricks” like the one he describes to implement polymorphism, but it makes sense that some creative solutions should arise to fill those functionality voids. I got really lost in the register allocation phase part of the podcast, I did not understand that part at all. It would be nice to
Leer más

Relevant Compilers design for students

  I will admit the article did get something I was thinking of the course, that the overall objective of learning to design a compiler seemed a little too niche, not something I would be doing as a job. But I did realize that the exercise of designing something like a compiler could give us some of the principles and experiences needed to design several other types of software. I previously to this reading haven’t realized that some of the experiences could be translated more directly to certain kinds of software, its just that a compiler sounds like a really specialized kind of program. I like the approach that the paper gives in that this course can help solve a broad range of problems related to translating. This paper helped me to better understand the phases of a compiler and what they do because I was still a bit confused and the example where it explains the translation from text to a drawing of a graph was specially useful as it felt simple and correlate each step to the resp
Leer más

SIF

  I would not consider the Clojure interpreter implement with Clojure that we saw during the Programming Languages courses as ‘cheating’, but certainly the SIF interpreter does look like a more interesting example. Just that S-expressions make me remember Clojure and I tried to like it, but I could not. While reading the article I became more impressed of Ruby as a programming language as it has some really interesting features such as the code blocks that I would like to learn better because I do not understand them completely, that every class even the base classes of the language can be easily modified, or that you can modify classes mid program although that one I am not sure in which situation would be used. Overall, I am enjoying Ruby a lot more than Clojure. The exercise sounds like a good way of improving object-oriented programming while better understanding interpreters and the particularities of Ruby, although the choice of Ruby as the programming language seems kind of we
Leer más