Inside the Tower of Babel

At the meeting of May 28 and 29, 1959, at the Pentagon, it was established that action had to be taken to build this new language, intended to make the use of computers far more accessible. This language was designated CBL – common business language. At this meeting, still according to the account of the pioneer Jean E. Sammet, other specifications were discussed and approved, for example:

• Most participants agreed on the use of the English language, although some maintained that the use of mathematical symbols should be favored.
• Favoring ease of use at the expense of the power of the language.
• The creation of three working groups, responsible respectively for the short, medium and long term.

It was then the working group on the short term that took charge of the concrete creation of the COBOL language, combining the best aspects of three languages existing at the time, used internally by different actors: Remington Rand Univac’s FLOW-MATIC, developed in 1958 under the direction of Grace Hopper; AIMACO (Air Material Command), developed by the US Air Force’s Air Materiel Command in 1959; and COMTRAN, developed by IBM in 1958. COBOL (Common Business-Oriented Language), the first major programming language to mobilize words drawn from natural language, was thus born from the work of a subgroup of six people belonging to the short-term committee, under the direction of Grace Hopper (1906-1992), another computing pioneer.

Since then, countless programming languages have been created, more or less specific, more or less close to the functioning of the machine, in which programs and data are inscribed in binary code. A “stratification” of languages has thus formed, differentiated according to their distance from the material foundation of the computer and their proximity to natural human language.

As can be observed in the table below, machine code makes no use of elements drawn from natural human language. Here are the famous “zeros” and “ones” of the digital, which are in fact presences or absences: of electrical charge for volatile supports (RAM), or of a particular orientation of magnetic elements (HDD hard drives); and, for the signal, the presence or absence of a sought-for value on a direct current. 1s and 0s are therefore in fact already abstractions¹ and the reading of the continuous at the level of supports and signals, with a view to discretizing the value read, is not at all trivial from a technical point of view².

abstraction
language
mnemonics
syntax
identifiers
Pseudocode (informal algorithmics)	(Not a real executable language)	N/A (informal connectives, e.g. IF, THEN, FOR…)	100% ( everyday language only)	Yes	Description in natural language structured like code. Example: "IF x > 0 THEN display "Positive"". No rigid syntax imposed.
Domain-specific language (DSL / high-level 4GL)	SQL (database queries) (1974)	60 (SQL-92 standard) to 100+ reserved words	70–80% (English syntax)	Partially	Declarative language very close to English. E.g.: SELECT name FROM Clients WHERE city="Paris";. Readable by a non-programmer. Free identifiers with quotes if a reserved word.
High-level language (interpreted)	Python (scripting, 3rd gen.) (1991)	keywords (in Python 3.x)	50–60% (concise syntax)	Yes	General-purpose language. Syntax close to English: logical operators (and, not, in). E.g.: for item in items: print(item). Significant indentation.
High-level language (compiled)	COBOL (business, 3rd gen.) (1960)	+ reserved words (COBOL-85: 357)	80–90% (very verbose in English)	Yes	Very literal English syntax. E.g.: IF NOT END-OF-FILE THEN MOVE TOTAL TO GRAND-TOTAL. Designed to be read by non-technicians.
Lower-level language (compiled)	C (systems, 3rd gen.) (1973)	keywords (C90/C99)	30–50%	Yes	Language close to the hardware. Few keywords, a lot of punctuation. E.g.: if(flag && i<10) total+=arr[i];. Very compact code, hence a low proportion of "natural" words.
Assembly language (assembler)	x86 asm (Intel syntax)	80 (8086) to 1000+ (x86-64)	0–10%	Yes	Native code made readable through mnemonics. E.g.: MOV AX,1; INC AX; JNZ loop. Abbreviated instructions (MOV, JMP, ADD, …) and registers (AX) are not everyday language.
Machine code (pure binary)	(e.g. x86 opcodes)	(No words, only binary codes)	%	No	A sequence of bits incomprehensible to humans. E.g.: B8 01 00 00 00 = MOV EAX,1. No abstraction: everything is addressed numerically. This is the language the processor understands directly.

At the immediately higher level of abstraction, we find assembler, a language specific to each machine, in which a hundred or so keywords³, most often formed by abbreviating words drawn from human language, represent the operations needed when programming the machine. These keywords are very specific: they often indicate an action, but also the object to which it must apply, and sometimes even the destination of that object⁴. More abstract than the “zeros,” assembler keywords are nonetheless far more concrete and specific than those found in higher-level languages.

COBOL, as we have seen, the outcome of a great effort to “translate” the functioning of the machine into a language comprehensible by humans, uses more than three hundred instructions, which are also, for the most part, English words, except that, unlike assembler, they always appear in full, without abbreviation. It is a language of great verbosity⁵, which earned it sharp criticism over time. Edsger Wybe Dijkstra, who received the Turing Award in 1972 for his contribution to the development of programming languages, was very critical of COBOL, and in this he expresses the feeling of a great many coders. For Dijkstra: “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence⁶.” Dijkstra was directly critical of any attempt to bring computer programming closer to natural human language, as his text On the foolishness of “natural language programming” bears witness⁷.

Languages such as C (1973), used to build the UNIX operating system, sought to be usable on different machines (a capacity known, for a programming language, as portability), while maintaining good control of the hardware. Much later, from the 1990s onward, languages of a new generation appeared, such as Python and C++, capable of describing object-oriented logics – languages that have become the most prized by professional and advanced coders. Finally, with the recent advent of artificial intelligence, Python has become the tool of choice for the new generation of coders⁸.

Object-oriented programming brings computer code closer to natural language on the semantic level, that is, in what these languages designate. In other words, with object-oriented programming, the symbolic plane draws closer to that of the entities of the real, of objects. On the level of syntax, however, object-oriented languages mark a departure from natural language, owing to the appearance of symbols whose readability is reduced, or even nil, for the uninitiated.

To conclude these paragraphs, let us say that intense and numerous efforts were needed to bring the logic of the computer’s functioning closer to human language. This rapprochement allowed a certain degree of democratization in the use of computers, henceforth within the reach of programmers and engineers⁹. Yet these efforts quickly reached their limits, while being carried out in a problematic way, through the implementation of strategies open to a political reading. Programming languages more efficient than their “verbose” elders – such as COBOL – eventually came into being over time: languages situated at a considerable distance from natural human language, and which remain rather unreadable for the uninitiated, and even, in certain respects, for experts. Their efficiency no doubt stems from the fact that they divide up tasks according to a symbolic representation of objects, thus approaching, on the semantic level, the way in which humans access the real.

1. Brian Cantwell Smith reminds us that being “digital” (digitality) is not a property of anything for a concrete element. See on this subject Brian Cantwell Smith, The Devil in the Digital Details (edited 2010, v75) [en ligne]. Madrid : Real Academia de Bellas Artes de San Fermando, Calcografía Nacional, 2010. disponible à l'adresse : http://www.ageofsignificance.org/documents/The%20Devil%20in%20the%20Digital%20Details.pdf.↩︎

2. Ibid.↩︎

3. For a 32-bit x86 architecture. This list of keywords reaches about a thousand for 64-bit architectures.↩︎

4. For example, PUSH means push data onto stack, ADC designates an addition with carry (like the one performed by the full adder presented above), and MOVSB implies move byte from string to string.↩︎

5. Using more words than necessary to describe an operation.↩︎

6. Edsger W. Dijkstra, Selected Writings on Computing: A personal Perspective. New York, NY : Springer, 1982, p. 130.↩︎

7. Edsger W. Dijkstra, «On the foolishness of “natural language programming” ». dans : BAUER, Friedrich L., BROY, Manfred, DIJKSTRA, E. W., et al. (dir.), Program Construction. vol. 69 [en ligne]. Berlin, Heidelberg : Springer Berlin Heidelberg, 1979, p. 51–53. [consulté le 20 June 2025].↩︎

8. The TIOBE index measures the popularity of programming languages among professional and advanced coders. See on this subject https://www.tiobe.com/tiobe-index/ accessed June 20, 2025.↩︎

9. It is less the availability of programming languages than the appearance of graphical interfaces that truly brought computer use to the masses.↩︎