Natural Languages and Programming Languges

Here I am with an article that has been on my mind for a long time. The topic I will discuss today is how much contexts in our lives are similar to each other. We can understand this not only with abstract subjects but even with the people around us. Whether we lived in different cities or had different experiences, we always share something somewhere. I have always observed these social relations, which are the nature of humanity, in the software industry and its applications. There are many examples among them, but in this article, I will consider only one.

Key to survival

As some of you may know, I completed my first undergraduate degree in English Translation and Interpretation in Istanbul. Contrary to popular belief, this field does not, and should not, give you intensive training on the grammatical aspects of the languages you will use in your future life. If you're already eligible for this section, you should already have a certain level of English-related grammar.

In this field, as I just said, students were taught more about how the cultural and professional contexts in which these languages are spoken function inside them rather than language-focused courses. There was an effort to have as many ideas as possible about many subjects such as Literature, Law, Medicine, and Mass Media. That's what's right. Because this thing called language, which we use to survive, is a tool that enables hundreds or maybe thousands of contexts to interact among themselves. And there are not only grammatical structures among the elements that make up it. The humanities and cultural pools in different contexts, which have developed over the centuries, also include a significant majority of these elements.

One part of the subject I want to write about here is related to this English Translation and Interpretation field that I graduated from; Similarities between natural languages and programming languages.

As you dig deeper into natural languages, it's impossible not to embrace the cultural networks that have created them over the years. If we look at the more scientific parts of the matter, thanks to lexicology, you can even see that natural languages have an almost mathematical system within themselves. It's like the syntax rules in programming languages that compilers apply to us.

Personally, the more I grasped the insides of these areas, the more appealing to me was the idea of the connection between programming languages and natural languages.

At the time, I took two courses called Special Topics in Translation and Legal Translation. These courses may be among the most boring ones I have taken in my university life, but these were the courses where I learned the most important concepts. I also think that most things that will improve us should bother or hurt us. For example, no Katmer or Baklava I have eaten so far has carried me forward in any context. Although, if we count the painful moments when I try to burn the calories I get from these, we can create an antithesis to this thesis.

Technical Part

Seven Standards of Textuality, put forward by two linguists, Beaugrande and Dressler, in 1981. With my notes I took in those classes, the features that a text should have, according to these people, are as follows:

Cohesion: Expressions that link a text to another text.
Coherence: It is the meaning and relation between the elements that make up a text.
Intentionality: In fact, what is wanted to be done and said.
Situationality: It is the power to evaluate. For example, a traffic sign only makes sense in its place. If its location is changed, it loses its functionality, and as a result, it does not make any sense. So each text is valid for its situation.
Intertextuality: It is the understanding and interpretation of a written text through its relationship with other texts.
Informativity: It is the state of being informative.
Acceptability: It is the compatibility of the situation in which the text is written with the purpose of writing.

The explanations I have given here are very shallow, I realize. But even if you are encountering them for the first time, they are items that you can get an idea of when you dwell on them a little.

I am also very confident that the practice of these standards on any text will strengthen that text. In my life, I also try to use it while writing blog posts, messaging with my social circle, or during any information exchange in business environments.

So what does this have to do with my professional career in Software Engineering? I want to give a very heartfelt answer; Almost everything.

Whether you are a person dealing with this job, or a different one. You might be aware that we, Software Engineers — Developers, Crafters, whatever unique label you can find, all of them — every day of the week, we stare at the screen in front of us for hours and write code with the keyboards at hand. In essence, we write texts.

Let's think about the seven standards of textuality that you have just seen above, in the texts we write in software contexts. From this perspective, please review each one and compare them to the standards we follow in software development processes.

Consider Best Practices, Clean Code, Separation of Concerns, Modular Design, Immobility as a Code Smell, SOLID Principles, and hundreds more, about which there are hundreds of books, Medium articles, podcasts, and training videos.

My positioning of these standards in software fields is as follows.

Cohesiveness standard

This standard reminds me of one of the most important paradigms in software, the concept of modular development. Just like separating each component that we use in our front-end or back-end projects into its separate files, namely modules, and then ensuring that they are combined in the most ideal way.

Contingency standard

I think, the example I gave in this article is very appropriate. Frankly, I liken it to the Single-Responsibility principle in SOLID Principles. A traffic sign has only one function in real life, conveying information to drivers and pedestrians. Just like the Classes we wrote should have only one reason to change, that is, they should have a single function.

Intertextuality standard

This is an item that brings to my mind the test files directly. I believe that if a code is written, it should be tested. The code that should not be tested anyway, should not be written.

The tests we write not only measure the reliability and continuity of the systems we design, but also enable them to describe them most simply and concisely possible. This is the reason why I look at test files every time I learn a new open source technology. If the tests are written in an ideal way, we can easily understand the functionality of the code.

Informative standard

Yes, I know, most of us as programmers avoid documentation. Especially if you work in institutionalized companies, I am aware that it is very boring to fill in ready-made templates that smell of bureaucracy.

However, it is still one of the important factors required for the systems we develop to be more open and convenient to users. Do not forget that the test subject I mentioned before is also very closely related to this subject. Because I think that effective test writing also feeds the Self-Documenting paradigm.

The End

As a software engineer, I hope you have experienced the same epiphany I experienced when I first encountered these seven standards of textuality.

I am very pleased and intrigued by the fact that the readable and simple codes required from us for the long-term continuity and effectiveness of the products we have developed, are also related to the effective use of the natural languages we use in our daily lives.

Thanks for your time, stay well!