The hypothesis of linguistic relativity and programming

I have heard about the Linguistic Relativity hypothesis for the first time when I was reading “Babel – 17”. Back then, I could not really catch the idea although the concept of a language transforming and improving thinking process definitely gripped my attention. Later when I came to developing programming systems I would often recall that novel relating its ideas to my activities. The hypothesis says that a language can alter the thinking process of its uses. On the one hand, it may sound as the statement does not hold water at all (after all, it is just a hypothesis). On the other hand, it does precisely reflect the main principle of psycholinguistics. Originally this hypothesis was based on the results of various ethnic groups’ natural languages researches.

A Natural language has two main functions: communication and thought (actually, the classification is a way more complicated [1] but I would avoid going into details). In a fact, the considerable variety of the functions that can be attributed to Natural languages might be the reason why proving the Linguistic relativity hypothesis is so hard. Formal languages, however, do not possess the communicative aspect which complies with the idea quite well.

Moreover, Formal languages can be easily compared to a set of tools (programmers would think of programming languages as tools). Mark Twain once said: “To a man with a hammer, everything looks like a nail”. As a result, programmers who code in a particular programming language usually build their problem-approach based on the “paradigm” of the language or its framework.

It is often said: “A true FORTRAN developer can write a FORTRAN program in any language”. The point is that FORTRAN is an old programming language that has limited options for programming code partitioning. FORTRAN developers were often using GOTO (imperative go-to statements) that naturally ends up with a program consisting of a barely readable spaghetti-code. As a result, a FORTRAN developer would usually write down some spaghetti-code even while using other programming languages that could actually offer advanced partitioning options.

Here is another quote by Edsger W. Dijikstra (one of the structured programming pioneers): “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC; they are mentally mutilated beyond hope of regeneration”.

Judging from my own experience I can claim that it might be unbearably hard to retrain developers who write procedural code and persuade them to use the object-focused approach as they should do. Despite almost everyone using the derivation and subclassing as well as the accessibility modifiers, many still write the procedural code instead of employing the statements designed for OFP.

These established thinking patterns are causing the professional deformation which may be considered a cognitive personality disorder. After this is said, it is time to switch back to the main idea of this article concluding all the mentioned above: the language that is used by a programmer is directly altering his or her thinking process.

After all, is this a problem of an advantage? Let us look through this one as well. Nowadays, we have a ridiculously large number of programming languages created. The main purpose of this is to provide an effective solution for a specific type of tasks. For example, C language can be a highly effective tool to code a core module using the hardware resources while JavaScript is naturally great for event model realization and SQL is a must for data operations.

However, if you try to misuse these you will be in a trouble for sure. Firstly, the statements you can code doing this would be complicated and unclear. Secondly, the number of code-lines would be alarmingly higher compared to the language appropriate for this task. That is why this is important to pick the right tools (including programming languages) at the beginning of a development process. A good choice of tools will allow you to sufficiently increase the production and quality levels during the development process. Let me quote a famous “No Silver Bullet” article by Fred Brooks: “Surely, the most powerful stroke for software productivity, reliability and simplicity has been the progressive use of high-level languages for programming[2]. However, the use of the high-level language itself will not give any positive results as long as the developers do not shift their thinking process to fit the paradigm of the language.

On the other hand, learning different programming languages based on different programming paradigms is widely broadening one’s horizons and allows finding a practical solution to any task – the same object can be seen from two different points of view [3].

  1. General Theory of Social Communication. A.V. Sokolov.
  2. The Mythical Man-Month. Frederick Brooks.
  3. Простые вещи: гвоздь. Михаил Петров.