4 Mother of Compilers

Grace Hopper is known for her contributions to the computing world. Which started at her position in the navy as a ‘computer’ for ballistic tables for WW2 after being a professor of mathematics. She served under Howard Aiken, the architect of the Mark I, which was a slow electro-mechanical computer. This huge calculator was a secret project at Harvard, and Hopper learned the coding aspect of it, which would later position her role as indispensable.

There was another secret project where another computer was stored, called the Eniac. Which was larger and could calculate more than the Mark I. These projects where so enormous that it consumed a major part of Hopper’s time. Even more so, because she and her team under Aiken where given a problem that was later reveled to be the ‘implosion problem on the nuclear bomb’. Which, as we know, was used in Japan to decimate the population.

After the war, Hopper is relieved of her duty in the navy and not allowed to be a professor again. So, she turns to a startup company which had the purpose of transforming the computer to be a household machine. It started properly with the Univac I, and Hopper’s contribution by implementing a compiler in 1951. Then, the basis of Cobol (Computer Business Oriented Language) was introduced to allow non PHD mathematics students to be able to communicate with computers.

I believe this woman’s path traced the journey of our programming world today. Her unwavering confidence to tackle problems in a different way than what was already established opened new lines of thought which constitute our contemporary programming languages. It is important to follow in her footsteps and not get comfortable with how things are now. We must continue to think programming as a tool to for a means, not a means for an end.

*All the information in this blog was referenced from these two sources: Pages 1 and 2 of the 2013 article titled “Grace Hopper – The Mother of Cobol” from the “I Programmer” web site. The video documentary “The Queen Of Code” (16 minutes long), directed by Gillian Jacobs in 2015.

3 Internals of GCC

In “Internals of GCC” by Software Engineering Radio with Morgan Deters as guest we can see a general view of how GCC compiler works. Morgan Deters says: “A compiler has to read a plain text, source file, and understand what that means […] anytime you use a variable it has to figure out which variable you’re referencing, how to access that variable, whether it’s a local variable or global variable […] and it has to understand the semantic content […] generally, compilers will produce some sort of internal representation to mull over this information, to understand it better themselves” And, the GCC comprehends a vast array of programming languages which can be implemented in a large scale of processors.

The GCC (Gnu Compiler Collection) can be run on various platforms and is very flexible. Its input and output support all kinds of code structure. Therefore, Deters promotes its usage for many different architectures. The compiler passes through various iterations or RTL (register transfer language) to produce a low level syntax tree produced from the source code that will be executed in the target language.

The GCC has a front-end, middle-end and back-end. Which Deters explains in a modular fashion. The front-end is language dependent but architecture independent. The middle-end can operate on anything. And, the back-end is language neutral but architecture specific. And by architecture, Deters means a specific instruction set common in a family of chips (example. Intel’s 32 bit chips). This means the GCC compiler is highly usable because of its easy integration to most types of software and hardware.

Although, not all of it is good news. By optimizing all of these things to a general and simple integration process, some of nodes of the high level tree are basically displaced to give way to a simple syntax which recurses in itself multiple times, and thus, making the code much faster but less efficient. Anyway, this seems like an excellent option for those who need to share their work to multiple platforms so their code can function anywhere.

2 The Hundred-Year Language

Paul Graham talks about an interesting idea in his essay  “The Hundred-Year Language”. He imagines what programming languages might be in a hundred years from now, and what current languages will disappear because of their ineffective essential axioms. He, in fact, uses an analogy to get his point across: “It's like the rule that in buying a house you should consider location first of all.” Where the house is the language, and the location is the foundation. Because you can improve the house all you want but not change its location.

We can also bring other languages to the table: human languages. Those not man-made. Their growth depends on context. English has become a business type language while Italian, to name one, has been confined to a more ‘artistic’ language. Human languages’ development has evolved in the same way a programming language, I think, will evolve. That is, programming languages will become more efficient by reducing their axioms. Although, other programming languages will not have this same evolution because they will evolve to be efficient and not convenient. But the author remains hopeful: “In language design, we should be consciously seeking out situations where we can trade efficiency for even the smallest increase in convenience.”

“Inefficient software isn't gross. What's gross is a language that makes programmers do needless work. Wasting programmer time is the true inefficiency, not wasting machine time. This will become ever more clear as computers get faster.” This is also a true statement. I believe the world thinks computers can do things by themselves, thus designing inefficient software where programmer’s time is wasted to give way to a faster implementation. And, this type of thinking brings more trouble than solution because it resolves an issue on the surface, but the foundation is ignored, which at the end brings more problems to be corrected. Which would not happen if the essential code were structured properly.

At last, we must rethink our way of designing programming language because what we use today will not be relevant tomorrow. But I can also see the difficulty in doing so because “[…] our ideas about what's possible tend to be so limited by whatever language we think in that easier formulations of programs seem very surprising.” So, it is hard to reduce anything to its core value because we tend to think in a much more superficial level.

All in all, I remain as hopeful as Paul Graham in that technology will not overcome us wholly. There will be programming languages that become irrelevant immediately, but we just need one to work properly so it can evolve at the same pace as future technology.