Compiler Design for Education Pt. 1.: Anatomy of Computer Languages

Our engineering field works with metaphors, heuristics, mnemonics, and much more. Sometimes, it even seems surprising to describe it as an engineering field, given how ambiguous and traditional its learning and teaching methods may be—we often think of language as something more related to anthropology and artistry. Anyways, in stating this, my intentions are not to open a discussion on my beliefs about what is, and should be, software engineering. With this, I am observing a learning behavior that, on one hand, tends to follow an oral tradition of education, which is not bad at all, but may obfuscate what really happens behind the machinery of parsers and interpreters.

These languages of ours, computer languages, fairly intersect mathematics and linguistics. Much akin how we learn about these topics in early school days by counting with fingers and singing songs of the alphabet, so happens with software engineering with the amount of advice, wisdom, and empiricism it involves. Again, this is not bat at all; in fact, it is great! However, problems arise when we stay solely at that level of comprehension and understanding. For instance, if we stay at the level of purely counting in fingers until college, well, you are going to have trouble solving integrations and derivations, let alone high-school algebra. You may have problems learning another language too. I see this sometimes in my studies, where we all too often stay on the level of empiricism of writing programs in a particular programming language such as Python and Java, a particular paradigm (which is Object-Orientation, of course), and mental diagramming tools (UML). So, such a limited experience of education becomes our own barriers, which ultimately inspire fear and frustration in testing other waters, territories, and ideas.

I am all for Compiler Design on our curricula. But I would love another interesting approach to it: that of anatomy. That is, to learn not the particulars of a computer language, but the generalities they share with other ones and the yet to come. I believe this kind of education would be far more enriching since, then, we would be able to relate the concrete implementations of a language through an abstract concept. In doing so, learning new languages and paradigms would become easier since there would be no fear of stepping on seemingly unknown territories—there must be a common safe and known place to step for this language to become that of programming, and perfectly contrasts the differences between these implementations.

Overall, if staying on a particular level of understanding lends oneself to becoming static on our viewpoints, then our field becomes static too. We must learn what makes ourselves, our field, and, ultimately, society move forward: its dynamisms.

 

Ortiz, A. (2008, March 12). Language Design and Implementation using the Interpreter Pattern. SIGCSE’08. Retrieved from: http://arielortiz.info/publicaciones/sif.pdf