Can we study programming languages in the context of linguistics? Do programming languages evolve naturally in similar ways to natural languages?

Although full rationality, and mathematical consistency is essential to programming languages, there still is the need (especially modern languages) to make them readable and comfortable to humans.

Are programming languages evolving to become more linguistic and thus more natural? For example machine code, punch cards and assembly languages have given way to more readable languages like Ruby and Python etc.

When I say computer languages are becoming more natural, I don't mean they contain more 'words we have in english', I mean they seem to becoming more like a natural language, in terms of their complexity of grammer and ability to express meaning (for example, being able to eloquently describe a query from a database in both rational and human understandable ways).

What do you all think? Are programming languages becoming more like natural languages, and thus becoming applicable to the laws of Linguistics?

Or perhaps languages live on a spectrum, where on one side you have the extreme rational languages and the other the more creative. Maybe, programming and natural languages are identical and both just lie on this language spectrum (their only difference, perhaps being the 'thing' they are trying to give their meaning to).

Is there a connection between the (Babel Tower effect) separation of human languages and of computer langages? Do they become more diverse for the same reasons (i.e. to solve different problems within ever-evolving computer-systems/culture-systems etc.)?

  • 5
    $\begingroup$ short answer: yes, yes they are. $\endgroup$
    – ryanOptini
    Feb 7, 2013 at 23:32
  • 20
    $\begingroup$ Short answer: no, no they aren't. $\endgroup$
    – delnan
    Feb 8, 2013 at 0:01
  • $\begingroup$ This question is being discussed on Meta. $\endgroup$ Feb 8, 2013 at 0:36
  • 3
    $\begingroup$ Computer languages tend to do well with terseness and precision, somewhat like mathematical notation, which has shown no particular inclination to evolve towards natural language (that I'm aware of) over the past few thousand years. I also doubt that if you communicated with your infant exclusively in Haskell for the first few years of his life he would develop natural language fluency. So, I think there is pretty sharp contrast between natural and computer languages. Perhaps wider spread of language construction techniques have improved the "naturalness" slightly over time, I suppose. $\endgroup$
    – psr
    Feb 8, 2013 at 0:48
  • $\begingroup$ @ryanOptini: Do C#, JavaScript, Python, or SQL look anything like natural languages? While they all use keywords from the English language, none of them are converging to a natural language format. COBOL may have been the closest, but I don't think that many people are using COBOL for their greenfield projects. $\endgroup$
    – Jim G.
    Feb 8, 2013 at 0:53

9 Answers 9


Not really, no. Programming languages have become more like natural languages only in the sense of “words we have in english” (sic).

A key feature of programming languages is that they are not ambiguous. When you write a program and execute it, it has a well-defined meaning, which is its behavior. If you want to write a program that works as intended (a difficult objective), it is important that the behavior¹ of the program be as predictable as possible. Programming languages haven't made much difference in the wide gap towards natural languages.

Conversely, there has been work in bridging the gap from the other side: analyzing natural languages with the same tools as programming languages. This field is called natural language processing. These approaches have been pretty much discarded in favor of machine learning. I'll cite a passage in the Wikipedia article which is directly relevant here:

Up to the 1980s, most NLP systems were based on complex sets of hand-written rules. Starting in the late 1980s, however, there was a revolution in NLP with the introduction of machine learning algorithms for language processing. This was due both to the steady increase in computational power resulting from Moore's Law and the gradual lessening of the dominance of Chomskyan theories of linguistics (e.g. transformational grammar), whose theoretical underpinnings discouraged the sort of corpus linguistics that underlies the machine-learning approach to language processing.

One way in which programming is evolving is that as we design larger and larger systems, source code is not always a good way of understanding them. For example, an Intel CPU is one of the most complex objects ever designed by Man, and its “source code” is not just a collection of text files, far from it. But the full design isn't evolving towards anything resembling a human language either. I don't know what the appropriate cognitive tools or metaphors here, and I don't think anybody knows just yet; ask again in a couple of centuries.

¹ Or rather the set of possible behaviors annotated with the circumstances under which they arise, but that's only adding one step of indirection in the modeling, so this isn't really relevant here.

  • $\begingroup$ It's worth noting that attempts to make "natural" languages that are more like programming languages have been, well, not too successful. See Lojban as the most-developed example. $\endgroup$
    – Danica
    Feb 9, 2013 at 6:41
  • $\begingroup$ comparison between CPU architecture and programming is somewhat disingenuous, hardware design has always been largely non text-based, as it has completely different problems to solve e.g. 2d placement and routing problems. (if anything hardware design is moving toward more text based design with HDLs) $\endgroup$
    – jk.
    Mar 4, 2013 at 15:08

an interesting case study in this area is Perl vs Ruby (and Python). Perl is a scripting language developed in early 90s that added much capability compared to prior Unix based scripting languages (eg bash). the author Larry Wall is on record as saying his background in linguistics inspired some of the language features.

however Perl has awkward syntax and many special cases that make the language somewhat like English in all its subtle idiosyncracies inspiring various levels of criticism. later scripting languages like Ruby and Python, developed by computer scientists, have much more consistency in their syntax. the main problem is that natural language has large amounts of ambiguity (this is studied in the field of linguistics.) so natural language will have a key place on future human-computer interfaces like Siri but those interfaces will inherently be subject to ambiguity problems.

so, here is a case where the evolution of computer languages went away from a natural language idea. moreover, the general history of computer programming languages is that they have been developed and changed to remove ambiguity (which is highly inherent to natural language). this was not understood early in the history of compilers (say possibly in the 1970s) and eg early versions of the Fortran language had statements with ambiguous meanings that depended on compiler implementation. some of CS language theory related to parsing was developed partly in response to the discovery of ambiguity in language parsing.

  • $\begingroup$ You have your dates wrong: Perl was released in 1987, Bash in 1989. It is also troubling to read your posting because of its capitalization errors. $\endgroup$
    – tchrist
    Sep 3, 2014 at 3:06

Computer languages tend to do well with terseness and precision, somewhat like mathematical notation, which has shown no particular inclination to evolve towards natural language (that I'm aware of) over the past few thousand years.

I also doubt that if you communicated with your infant exclusively in Haskell for the first few years of his life he would develop natural language fluency. So, I think there is pretty sharp contrast between natural and computer languages.

Perhaps wider spread of language construction techniques have improved the "naturalness" slightly over time, I suppose, since programmers "vote with there feet" by using languages that seem easier to them and the number of people capable of creating languages has gone up with more practitioners and better tools, but this is a small effect around the edges and doesn't represent a fundamental transformation of programming languages into human ones.


Machine language is very precise, while a human-written text can usually be interpreted in many different ways (some poetic text for example).

What is more and more evolved is patterns matching, for example when you write some ugly code a compiler can help you proposing several possible solutions and then throw some warning or error that can help you exprime yourself. (based on common code patterns for example)

There is specific research on interaction/design patterns, even T9 and SWYPE are patterns recognizers that help a lot you (programs that records your voice and convert it to text are patterns recognizers too).

Of course a program is something that relies on precise mechanisms so you need precise languages (not natural), while a simple web search on google is very natural, you just have to type few words and you get what you want.

Every different task and goal has its own language, that's not a simple "single language evolution" there are much more languages. Precise tasks need precise languages and relaxed tasks requires relaxed languages

You can write the same piece of C code and then compile it with several different compilers, and (unless some compiler is bugged) the result of the code will be the same even if different assembly is generated, while for a web search givin the same keywords to different search engines gives different results.


Some years ago my elder son and I developed a Plain English programming and development system in the interest of answering the following questions:

  1. Can low-level programs (like compilers) be conveniently and efficiently written in high level languages (like English)?

  2. Can natural languages be parsed in a relatively "sloppy" manner and still provide a stable enough environment for productive programming?

  3. Is it easier to program when you don't have to translate your natural-language thoughts into an alternate syntax?

We can now answer each of these three questions, from direct experience, with a resounding "Yes".

Our parser operates, we think, something like the human brain. Consider. A father says to his baby son:

"Want to suck on this bottle, little guy?"

And the kid hears,

"blah, blah, SUCK, blah, blah, BOTTLE, blah, blah."

But he properly responds because he's got a "picture" of a bottle in the right side of his head connected to the word "bottle" on the left side, and a pre-existing "skill" near the back of his neck connected to the term "suck". In other words, the kid matches what he can with the pictures (types) and skills (routines) he's accumulated, and simply disregards the rest. Our compiler does very much the same thing, with new pictures (types) and skills (routines) being defined -- not by us, but -- by the programmer, as he writes new application code.

A typical type definition looks like this:

A polygon is a thing with some vertices.

Internally, the name "polygon" is now associated with a type of dynamically-allocated structure that contains a doubly-linked list of vertices. "Vertex" is defined elsewhere (before or after this definition) in a similar fashion; the plural is automatically understood.

A typical routine looks like this:

To append an x coord and a y coord to a polygon: Create a vertex given the x and the y. Append the vertex to the polygon's vertices.

Note that formal names (proper nouns) are not required for parameters and variables. This, we believe, is a major insight. My real-world chair and table are never (in normal conversation) called "c" or "myTable" -- I refer to them simply as "the chair" and "the table". Likewise here: "the vertex" and "the polygon" are the natural names for such things.

Note also that spaces are allowed in routine and variable "names" (like "x coord"). This is the 21st century, yes? And that "nicknames" are also allowed (such as "x" for "x coord"). And that possessives ("polygon's vertices") are used in a very natural way to reference "fields" within "records".

Note, as well, that the word "given" could have been "using" or "with" or any other equivalent since our sloppy parsing focuses on the pictures (types) and skills (routines) needed for understanding, and ignores, as much as possible, the rest.

At the lowest level, things look like this:

To add a number to another number: Intel $8B85080000008B008B9D0C0000000103.

Note that in this case we have both the highest and lowest of languages -- English and machine code (albeit in hexadecimal) -- in a single routine. The insight here is that (like a typical math book) a program should be written primarily in a natural language, with appropriate snippets in more convenient syntaxes as (and only as) required.

You can get our development system here: www.osmosian.com/cal-3040.zip . It's a small Windows program, less than a megabyte in size. If you start with the PDF in the "documentation" directory, before you go ten pages you'll be recompiling the whole shebang in itself (in less than three seconds on a bottom-of-the-line machine from Walmart).

Questions and comments should be addressed to [email protected]

  • $\begingroup$ Are you aware of attempto.ifi.uzh.ch/site/description controlled english? you seem to be sitting between that and Inform7 en.wikipedia.org/wiki/Inform#Example_game_2 $\endgroup$ Feb 10, 2013 at 23:25
  • $\begingroup$ I like the idea, but it seems there are still some syntax hoops to jump through. For example, i don't think i or anyone who's modeling geometric stuff would consider the X and Y coordinates being added separately, so "To append an x coord and a y coord..." sounds really odd to me. As does "Create a vertex given the x and the y". Nearly forgivable since it actually reads mostly like English, but still seems too strict. Maybe i'm just too used to not thinking like a human or something, i dunno. $\endgroup$
    – cHao
    Feb 20, 2013 at 14:48

Separation of human languages come from (darwinian ?) evolution in isolated communities. Separation of programming languages comes from variations in technical need, technical ideology, from changes in technical and theoretical understanding, from changes in our technical ability to implement. It is a somewhat more conscious process, I think.

Could computer languages be more like natural languages ? Probably somewhat, up to a point. I guess that a large part of natural language complexity results from a variety of concurrent evolution phenomena that have no reason to produce a consistent result at any one point in time, even though it is likely that old inconsistencies are probably progressively eliminated while new one appear. I am no expert in diachronic linguistics. But do we want that kind of complexity in programming languages.

The issue of ambiguity is an important one, but not as stated by most people. A language is a mean of communication, and it must be analyzed in the context of that communication (man-man, man-machine, both, between places or between times, ... to say it a bit simplistically). What matters is not whether you can make only unambiguous statements in the language, but whether you can always ensure that the communication will be unambiguous in its intended context. There is one well known and widely used programming language, that allows writing ambiguous programs (well, it did, but I have not looked at the latest versions for a while). In this case, the compiler is smart enough to detect the ambiguity and ask for clarification, which can be incorporated in the program the eliminate the ambiguity. Note that ambiguity detection does not mean that only one of the possible choices has meaning, they all do. The issue is whether one of the communicating entities can detect the ambiguity so that the sender can clarify it. Human beings are bad at this, but computers can be pretty good.

Formalisms and programming languages could have richer and more flexible syntax. I believe the main reason they do not is simple conservatism. The syntactic tools used are still very often tools designed thirty years ago or more, to meet the limitations of the computers of that time. Parsing efficiency is no longer such a critical issue in compiling and more powerful techniques do exist tractably.

Interestingly, the most widely used basis for programming languages syntax comes from natural language research : the context-free grammar. Much of the technical research moved the to theoretical/technical computer science in the sixties, to be somewhat rediscovered in the early eighties by natural language people (I am simplifying). Since then, much progress has been made for syntax in natural languages, while computer science seems largely stuck with old syntactic tools. The natural language pendulum is now swinging again towards statistical techniques, but algebraic approaches for syntax are not forgotten. Most likely, good approaches will come from a combination of algebraic and statistical techniques.

My feeling is that the critical area is semantics and the transition between syntax and semantics. This is still very hard to formalise for natural language, while we have many precise techniques in the case of programming languages and formal systems. As the game is far from being played for natural languages, it is hard to say what impact it could have on programming languages in the future.

Another point is that many programming language designers are trying to prove something or enforce a technical ideology. Thus they get extremely prescriptive in their design to prevent users from departing from their intended paradigms. This is unfortunately extremely counter-productive for creativity. The most creative language ever designed was among the very first : Lisp (1958). The freedom and flexibility it allowed was the source of considerable creativity. The price was that it required self-discipline and understanding. But Lisp was really a metalanguage, a language for the creation of languages.

Now, to take another perspective, programs are actually proofs of their specification seen as a mathematical statement (well, I am simplifying again). Some people (I do not remember references, sorry) have been playing with theorem provers to produce proofs that would look like they had been written by a mathematician in natural language. So I guess the idea of having programs that look like they were written in natural language may not be totally absurd.

You may however notice that, even when written informally by a mathematician, mathematical discourse looks quite different from ordinary talk, or from a history book. This is due to a significant difference in the concerned universe of discourse, the semantic domains that are being talked about. Thus while you can envision programming languages that look more like natural languages, there is a natural limitation which is the domain of discourse and its own desirable properties. Most likely it will remain essentially superficial, that is, mostly syntactic. The mathematician can talk about formal systems and about politics. Hopefully the two discourses will not look similar. Computers cannot (yet?) talk of politics, or understand it. The day they do it will no longer be programming.

Looking back in history, high level languages were, from the very first (FORTRAN) an attempt to get closer to a more natural form to express computational tasks, but these tasks were understood as mathematical or logical (Fortran 1957, Algol 1958, Lisp 1958), or more business oriented (Cobol 1959). Within 10 years people were worrying about languages that would be closer, better adapted to the problem at hand, and there was significant research in so-called extensible languages, covering both syntax and semantics. One major pathway for expressing problems more naturally was the emergence of object orientation (sometimes under other names). Though it is always difficult to assign parenthood, it probably emerged from the work on artificial intelligence, mostly in Lisp, and from the language Simula 67 (Algol family) which was itself intended to express more naturally real world problems that are to be simulated on a computer. It all seems historically consistent.


Although they are similar in that the asked questions are similar, they are quite distinct in terms of complexity. The main difference is that natural language is inherently ambiguous (even at the level of words). It is even not clear what is meant by a word? In the world of programming languages however, a variety of defining devices are at disposal. Look at grammars for parsing natural language and those for parsing programming languages, the difference in size is stunning. The thing is That grammars for programming languages are formal systems; so they are amenable to mathematical analysis. Dealing with ambiguities pops up many problems for which a solution in the programming language counterpart would be trivial or simple.

Maybe the gap between natural languages and programming languages will shrink if the gap between computer scientists and "natural" people shrinks.


In the past years, the interest in (E)DSLs and fluent interfaces has been steadily on the rise, in a great variety of languages: Haskell, the various scripting languages, C#, Java, and even C++ (think of the overloading of operator<< for doing output).

To some extent, these allow code to read more naturally. I'll illustrate with an EDSL example in groovy. The groovy.time package allows you to write

use ( TimeCategory ) {
    // application on numbers:
    println 1.minute.from.now
    println 10.days.ago

    // application on dates
    def someDate = new Date()
    println someDate - 3.months 

If you were to do this via the java.util.Calendar class you would have to write something like this for the first example:

void demo() {
    Calendar date = new GregorianCalendar();
    date.add(Calendar.MINUTE, 1);

Computer languages (even the rudimentary machine languages of days long past) are human languages, as they are primarily for communication with fellow human beings, are defined by humans, and are used only secondarily to convey instructions to a machine. So they evolve much the same way "natural" languages evolve (just look up "idioms" for your favorite language, check on how e.g. C has evolved from K&R C to current ISO-C 2011. But they exist in a different environment, they must convey precise meaning (computers are still too dumb to make sense and correct what is asked of them), and there is a premium on ease of processing (thus the grammar and vocabulary of even C++, PL/1, or APL are much simpler than e.g. English, which as natural languages go is rather simple).

Much the same thing can be said of the formalism of mathematics or the sciences in general, or even blueprints (inherently 2D, not 1D as the others are).


Not the answer you're looking for? Browse other questions tagged or ask your own question.