Is there a reason to believe that programming languages are going to converge?

Question

On Earth today, even though most people speak some English, there is seemingly no reason to believe that future generation's main language will be the same in decades/centuries to come (i.e., we'll keep having different native languages and learn a common language later on in life).

Similarly, there are a bunch of different programming languages. But the iteration process is much much faster here. New programming languages are created on a regular basis, old ones become obsolete...

Is there a reason to believe that programming languages are going to converge into a single language in the decades/centuries to come?

Answer 1

It's not technically possible, at least without giving up functionality.

For example, languages have different levels of strictness which is proportional to how high or low level they are. Scripting languages are softly typed because they can easily perform runtime type checks and conversions. Compare this to C/C++, which has much more difficulty with type flexibility due to being closer to the memory. While more type-agnostic features get added, at the end of the day, most of these are still compiler-based: they serve more as programming aids than actual language functionality.

Another major example is how memory is handled. In scripting languages (and even some compiled languages), memory is largely out of the hands of the programmer, managed by the interpreter or some other system. In contrast, lower level languages provide the ability to directly manipulate and access memory, such as C/C++'s pointers.

While it's possible to think that maybe with increasing performance we'll someday stop caring about low-level programming and all start using some weird PHP analog for everything, I think that's failing to understand how the world really works. I consider C/C++ a low-level language, as do most people; but once upon a time, and still among some, it is a high-level language, and low level would be the likes of assembly. This is not merely terminology: as the performance framing of the question of efficiency shifts, so too do the measures of it. Simplifications we might now consider too costly to implement even in interpreted languages might one day be common-place among "high-level" languages, Java might be considered "low-level," C/C++ might be relegated to those weird times you simply must use it like assembly is now, and assembly itself might even be forgotten as an in any way viable language (class) in itself.

I think it's much less likely programming languages will converge than spoken languages for that reason. Human language serves a single fixed task, to convey information. While you might argue different languages are better or worse at some portion of that goal than others, they can all accomplish those goals. There are, however, things you simply can't do in PHP. There are also things no sane person would want to do (these days) in assembly.

One way to think about it might be this. If everyone in the world tomorrow spoke fluent Welsh, what would happen? Well, everyone would be able to converse in Welsh, translation services would go under, and perhaps leeks would become more popular. If tomorrow the only programming language available was JavaScript, we'd all be utterly screwed.

That's not even counting inertia. In human language, inertia is mostly a matter of being able to read old works of literature, something which is rarely a decision when deciding to learn a new language, and never a decision when learning a native language. While losing understanding of classic works would be a cultural loss, it's not likely to motivate actions on a large scale. On the other hand, having to reprogram the Linux kernel, Windows, almost every device driver, and web servers would definitely factor into broader decisions of programming languages. That COBOL still lives is a fairly strong argument against programming language convergence, in my opinion.

However, there is one point you might expect some convergence in programming languages: syntax. That is already happening, and the C-like family has largely won. C, C++, Java, JavaScript, and PHP all share mostly identical syntax, abet with some changes in operators, mostly mirroring their inherent difference. No pointer-operating * and & in PHP, no fun and easy string concatenation . in C. However, those aside, these languages are almost entirely mutually intelligible in at least structure. An alternative family would be the BASIC line, including VB and I'd argue Python.

Answer 2

Is there a reason to believe that programming languages are going to converge into a single language in the decades/centuries to come?

As a programmer myself, I certainly would hope not. It would likely be a massive inconvenience for virtually everyone, and benefit practically noone.

Different languages are good for different types of tasks. If you're writing a short script to hide a field on a web page when a user makes a particular choice in a form, you don't need C's ability to directly manipulate any addressable memory address, but you can't really have C without the concept of pointers. (You can avoid using them, but that is quite limiting in terms of what you can do; for example, you now have no language-native construct that you can use for variable-length strings, so you need to go reinvent that wheel.) If you're writing an operating system to run on bare metal, Javascript's lack of calling convention control, memory management and interrupt handlers is going to make the task nigh impossible, if not outright impossible. If you're teaching someone the basics of programming as a concept, assembler isn't going to cut it (it gets far too much into the gritty details of adding two numbers or accessing memory); on the other hand, if you are writing the critical section of a high-frequency interrupt handler, PHP probably isn't the language you're after. A garbage-collected language like Java is a poor choice for a real-time system where execution predictability is a requirement, because in most GC languages, the garbage collector can technically kick in at any time and start shuffling through your data, both taking up CPU time and causing cache flushes. Writing set-based data queries in C is a pain, but SQL makes it at least relatively easy to express what you want done with your data, rather than the mechanics of how to do it.

And it goes on like this. While there certainly is some degree of overlap, for example between languages like C# and Java, or BASIC and Pascal, in many of the commonly used languages, each programming language fills a specific niche. The choice between, say, Java and C# is fairly arbitrary (neither is obviously better than the other in the general case, though one can be better than the other in any specific case); the choice between Ada and C++ is not arbitrary (there are things you can do in one that you can't do in the other, or can't do without significant bending of the language).

Even if we disregard architecture-specific languages such as assembler, which is already quite a major hand-wave (what are you going to write the bootstrapper "BIOS" initialization and operating system bootstrap code in; binary machine language?), at least with the technology of computers as we know and recognize them today, there is a multitude of tasks that need doing, and the requirements are different for each. Performance, predictability, ease for the programmer, API accessibility, scope of features (both what is needed, and what is explicitly not needed or desired), and so on and so forth. In some cases, certain features are an absolute requirement for the intended purpose of the language; in others, lack of certain features is a feature. As pointed out in the comments and also elsewhere, some specific features are by their very definition provably incompatible with each other, regardless of how they are implemented or expressed, and thus cannot possibly coexist in the same programming language, so any such language would need to trade one for the other. Now consider the people who for one reason or another actually need the feature that got cut; what programming language will they use?

All this would seem to make it highly unlikely that it all converges into a single programming language that is equally suitable for writing an operating system kernel and a field-hiding script for a web page (or whatever replaces web pages in your scenario). I would even go as far as to say that it realistically won't happen.

If you want computer programming to appear realistic in your world, you need to allow for the fact that different tasks require different tools and that these different tools are going to be used by different people. A programming language is one such tool, and as such just as we today have both power tools and manual tools that accomplish the same thing -- say, making a hole in a wall -- there will almost certainly exist different programming languages which are suitable for different tasks.

And that's without even touching on the subject of rewriting every piece of software, or its equivalent, in EZ++2108. Which, no matter how productive someone can be in this new language, would be a gigantic undertaking.

Also compare Why are there so many programming languages? on the Computer Science Stack Exchange, and Why do people use C if it is so dangerous? on the Programmers Stack Exchange.

Answer 3

TL;DR It is not impossible, but I pretty much doubt it.

---

There are already good answers, but I wanted to add a slightly different point of view.

First, spoken languages are NOT a good analogy for programming languages. Indeed, in their nature they differ considerably. Excepting the conlang, the spoken languages are the results of centuries of evolution. Separation increased the difference, but communication tends to bring them more homogeneous. The main idea is to communicate with each other, to understand each other and exchange (or do business). Nevertheless, those languages are spoken by many speakers, and no-one or no-body actually control the evolution of the language. Even bodies like the French Académie Française merely reflects the evolution of the language, a posteriori. There isn't any reflection on "best" or "more efficient".

IMO, there will be an ever converging use of "English" as a communication language, but even this will diverge from the actual English. And I also doubt the other languages will completely disappear due to the inertia, mentioned by Wiliam Kappler.

At the other side, programming languages are discussed by collaborations, which sets standards. The most well known is the ANSI for C. But most of the languages have a group of people involve in deciding on the evolution of the language. It changes completely the nature of the evolution of programming languages compared to spoken languages.

Now, could those be merged? I would say it is not impossible. If you look back 10-15 years ago, few would have imagined how much a language like Java would spread. Indeed its size, performance, compilation time was considerably worse than, say C++. But since then, the language, the JVM and compilers have considerably improved. And furthermore, the progress in computers mean that a few more MB here or there, and execution difference are barely noticeable in most of the user's experience.

In microcontroller, there is a trend to adapt more and more ARM-architecture. Which seems to indicate a merging of the hardware. And if we see the OS war for mobile applications: e.g. Microsoft coming back to ARM, or tablets, smartphones, etc. If they manage to actually have a single OS running on all systems, that would facilitate a uniformisation of programming languages. As the price of the memory reduces, there will be less incentive to actually use low-memory solutions, allowing applications of bigger OSes (see how "low" the Linux gets through Embedded-Linux).

However, I see four arguments against it.

As the other answers point out, programming languages tend to be specialised in niche. I could see a few axes to differentiate languages

• accessibility: how easy is it to learn the language/read a program?
• efficiency: that is already three-fold: size of the bin, amount of RAM and speed
• functionality: what can we do with the language?
• portability: what is the scope where it can be implemented? How easy is it to reach our customers?

And there are probably a few more. Now, the only way to get the languages unified, is to get a language to be the best in all those axes. Just to give some illustration,

• ruby is easy to read and to learn, but not particularly efficient,
• Java is widely implemented, but too large/complex for embedded systems,
• C can be very efficient, but hard to learn (comparatively).

Due to these different axes and the specialisation that we observe today, it is doubtful that one of the language evolves to dominate the others.

We also have to consider the inertia of change. Programming languages have been born in a fully connected world (amongst their users). Therefore more communication will not modify their course (as for the spoken languages). Most of the users are reluctant to learn new ones, and often wait until the last moment to resort to learn something new. But "natural selection" could play here, favouring those who do. But together with the programmers, the inertia of programming languages is written in their code. In many research domain, Fortran is the language of choice (I have even seen code in F77), although 1) research is often aware of the new tools, and 2) some would argue Fortran is a deceased language. But why? Because a huge amount of code was implemented in those Fortran! And it would be a huge effort, and would probably prove impossible to translate all of it to another language (the original writers being unavailable, hard to check the science behind). The same goes for other large code: no-one is likely to rewrite the Linux Kernel. You need to implement compatible languages. But even then, that means that the "old" language still needs to be kept up to date.

The effect of the anarcho-liberalism of programming and Internet. It can be well seen with the numerous forks on FOSS: if someone disagree with a decision on the new standard, she is likely to either stick to the old, or create an alternative. Much like, as pointed out by Wiliam, many current languages derived from C. And if we could rely on the last 30 years or so, we see that the number of applications of programming languages explodes, most of the languages evolves, some appear as derivation of those, others as new concepts (rarely). But older standards are still being used today. So there is a multiplication and diversification of languages. It is hard to imagine that this trend would reverse.

Last of four points, the irrationality of the actors of the sector, a.k.a. programmers. New languages are implemented for the sake of irrational factors: Whitespace being a perfect example. Some people will defend the elegance, the poesy, etc. of their languages. This create some of the famous internet flame wars. I suggest you look "C++ vs Java" up. Take some bandage along. New users often side along one of the sides. As we have seen in the famous infamous emacs vs vim war.

To conclude, I would say that I can see a scenario where HW memory becomes cheap, HW architecture becomes limited to a few (X86, ARM) and that one OS is predominant on all of those. A new language appears that is the best or almost the best on all of the axes above. Then, given enough time, the other languages might die out.

But really, the easiest would probably to get an evil-genius dictator taking control of the world and forbidding any language other than assembler. Because who needs anything else?

Answer 4

TL;DR: No. Programming languages are too diverse.

Reason 1: Purpose

There are, according to Wikipedia's list of programming languages, 806 distinct programming languages, excluding BASIC dialects and esoteric programming languages.

There are some features of each language that wouldn't be too hard to merge: most programming languages have some form of conditional processing, variable declaration, arithmetic and mathematical operations, output, and input - among the other similarities. These are the parts that would be relatively easy to merge together (as long as we can decide on a style, which might take quite a while...).

There are other parts of other languages that cannot easily be merged, many of which depend on the purpose of the language. JavaScript, for example, is a dynamic Web scripting language used to give webpages interactivity. A lot of it is used here on StackExchange to load content dynamically without having to reload the page. This process is called AJAX.

AJAX is designed for the web. It is not designed for desktop applications, such as could be written in Java or C# or C or C++ (etc etc), that can be multithreaded and load content dynamically without a mention of AJAX: that's just how these languages work.

Taking JavaScript and Java as an example, we can also see that the purpose of the programming language matters. JavaScript is designed for the web; Java for installation on a system. JavaScript, therefore, has no file access, for security reasons - to ensure malicious websites can't access your files easily. Assuming this theoretical coverall programming language (which I'm going to call Σ∞ or Sigma Infinity) also has to suit every purpose, it has to be suitable for both the web and the installed versions. To satisfy this requirement, the language designers would be forced to release two different versions of the language - one without file access, one with - to maintain security.

As maintainers of modular languages or languages with multiple versions will tell you, this is a big task - ensuring that both versions are...

• Compatible with each other
• Up to date
• As close to identical as possible
• Supported
• Tested
• Documented
• Used

...is a big ask. You'd need to create a huge company to support Σ∞.

No, it is true, this does not preclude the possibility of Σ∞ existing. However, since we're talking practicality here, it is more practical for multiple companies to maintain multiple languages than it is for one huge company to maintain Σ∞.

---

Reason 2: Features

806 programming languages contain a lot of features. Ignoring the compatibility problems of purpose that we've just discussed, creating Σ∞ is going to take a long time simply because of the sheer volume of stuff the creators have to include. For every language, the creation process might look something like this:

Looking at an old post on StackOverflow, it seems many developers spend much more time bug-fixing than writing new features. Therefore, it's going to take a long time to even get one feature implemented, let alone one language, let alone 806 languages.

Yes, I may be exaggerating slightly, and you can just hire a lot of developers, but the time and the money going into the Σ∞ project are going to be significant.

---

Reason 3: Filesize

A simple one, and one more easily overcome than the previous two but still worth mentioning. The C redistributable and runtime take up 37MB, compressed, on my computer. That's about 45MB uncompressed. Assuming that C is a representative language in terms of filesize, that gives us 38700MB or 38.7GB as the total size of Σ∞.

That's slightly less than I was expecting, and certainly not a lot in terms of storage requirements. However, Internet connections need to develop significantly before downloading such a file - users don't want to wait too long for installers to download a single file, especially if there are more files to download for the program.

As I said, this problem is much easier to deal with: we're talking the future so you can probably assume better internet connections. Just a point worth mentioning.

---

Reason 4: Typing and Compilers

This has been covered in other answers, so I'll just go over it quickly: depending on the language's purpose and level within computing, the compilation and runtime processes differ significantly.

JavaScript, for example, is interpreted, at runtime. The browser's code translates JS into runnable code just before it's run. Additionally, JavaScript is weakly typed - you don't have to declare that this variable is an integer and this is a string, you just say var.

C#, by comparison, is a strongly typed, precompiled language. You do have to say that this is an integer and this is a string, and your code won't compile if you don't. (OK, there's var in C# too, but it still gets typed at compile-time.) Additionally, you have to run your code through a compiler, which turns it into an executable that you can run.

Merging the two types of languages would be rather difficult, if not impossible.

---

Finally...

I conclude, therefore, that there are too many programming languages, and too many different types of programming languages, for the Σ∞ project to be feasible - let alone practical.

Answer 5

Hopefully not.

Programming languages should never be governed by the laws that let natural languages converge.

Now we do have C++ which is the English of programming languages, indiscriminately borrowing stuff from other dissimilar languages at various points of its history (probably the worst idea in its history having been the syntactic dump of Ada generics into template syntax). C++ can no longer be sensibly described by syntax diagrams and no longer sensibly be parsed by parsers of a reasonably regular class. Its standards waver back and forth across semantics every few years, and just now variable-dimensioned arrays, which would be required to implement generally useful numerics libraries competitive with 50-year old FORTRAN libraries, have been kicked out again.

Sort of like getting rid of plural "ye" in English.

Now compare to a language like "Lua": syntax fitting on a single page in the reference manual (which is A5 size paper, about half Legal), a single data structure, few scalar data types, OOP programming techniques are implemented per protocol rather than by syntax and so on.

Merging it with C++ in any manner would make no sense.

Now somewhat interestingly there is a convergence of computer languages at the target level: there are no dedicated Lisp machines like Symbolics any more, and current architectures favor stack addressing with a shared return and data stack, a common program and data address space, with a function call/return (rather than stack switching/coroutines) paradigm for organizing control flow and a heap only working with data rather than function call/return (like you need for full Scheme continuations).

This leads to various programming languages having different performance characteristics and consequently different choices of programming language depending on the required level of matching the programmers' or the computers' thinking.

So you get to the situation where "high-level languages" are often implemented in a low-level language (Lua in C, for example) rather than themselves in order to get a system that both computer and programmer can get along with without too much pain.

This fundamental split shows no sign of going away. Virtual machines shift the compromises around a bit and put in another level of layering but don't really change that.

Answer 6

There are a lot of good answers given here, generally taking the no view.

I'm going to say yes, because we will eventually create software which is intelligent enough to write code much better than humans are able to write code. Some time after this event human programmers will become obsolete.

By a well known argument, this machine will repeated rewrite its own code, increasing its intelligence with each iteration. Assuming there is a limit to machine intelligence, it will rapidly converge onto this level of intelligence and the language it uses will similarly converge onto an ideal.

Answer 7

Could there be a single programming language in the future? Certainly, but let's take a look at why we have so many today.

There's currently a horde of languages that are or have been used, but that list doesn't really demonstrate why we have different languages today, so let's use this list of languages by type instead.

Scripting languages like bash and ksh are good for simple, procedural tasks that have to be done over and over again, but these don't provide all the functionality needed of large applications. They're more support structures.

Compiled languages like C++ and Python both have great strengths. The former has support for fine memory control and resource management. Python is intended to be easy to read and the source code short, certainly much shorter than C++. These two languages also operate at different levels: C++ is a low-level language (the source code looks like the system instructions) and Python is a high-level language (the source code looks like spoken language).

There's also Prolog, a fun language that functions like a database language with rules and queries. Prolog is based on logic rather than procedures, as bash and C++ are. As a result, it's good at mimicking intelligence (AI systems) and not so great at manipulating registers in memory.

Each of these languages has its own syntax and parsing rules. Someone who understands C++ can usually get a pretty good idea of Python code does by looking at it, but bash and Prolog are so different as to be unreadable from one to the other.

But syntax doesn't really impact what's supported in a language. The working draft for the 2014 C++ standards is more than 1,300 pages long. It's definitely not a simple language.

Unless there's a major breakthrough in language construction and application, I expect programming languages to remain as separate structures to focus on specific activities. We might see a smaller pool of languages used, but I don't expect that number to ever reach one.

Answer 8

It could converge into one language, but it would be very diverse.

Metaprogramming is where your code interacts with the code itself. You could have one programming language, but different use areas would use it very differently, perhaps even incompatibly. In the end, the language would be very advanced.

Interestingly, LISP, one of the oldest languages, is probably the most likely to do this. In LISP, the source code itself is also the most common data structure, a list. A LISP could potentially have different "sub-languages", which would have different parts of LISP. This is sort of like Haskell's Monads.

Haskell is another interesting case to consider. It is very mathematical in nature, so compilers can mathematically manipulate it to make programs faster. Also, it has Monads and DSLs, which are basically programmable sub-languages. You can program your GPU in haskell, (namely, the haskell program makes the program for running programs on your GPU.)

It should be noted that although they exist, both Lisp and Haskell on some what obscure. They are on the rise though, so in the future, we could imagine we have some sort of super language, in you which basically make the program program itself. This would allow a lot of different use cases.

It should be noted that this one language would look like a lot of separate ones mushed together from a distant, even though its core could be one simple base language. A library would basically be a language.

Answer 9

As much reason as believing that human languages will converge.

A long time ago people forecast a rapid convergence of human languages, Yet this is yet to occur. Programming languages have an aditional feature that are not present in human languages, they are invented languages by nature (in contrast with Esperanto and other invented human languages that are an exception, not the rule). This means that while human languages might converge due to natural evolution and the increase in communication provided by technology, something that might cause the creation of an universal language in the future, spoken by the absolute majority of the global population, and even if computer languages are subject to the same principles of convergence, we have the added factor that new computer languages are created every day. Some new languages, might achieve hegemony on a certain niche and later expand towards becoming a general porpuse language. We cannot rule this out.

So, i believe that computer languages will always be an heterogeneous field. Even older computer languages that are considered obsolete (I am myself a Pascal programmer), can receive a new treatment and become modern. Pascal faces a lot of prejudice from people who know it only from texts like Kerrighan "Why Pascal is not my favorite language", yet, modern pascal is much more advanced than C language, with a complete set of object oriented aditions, and none of the things that Kerrighan criticized in that popular essay. So, i believe that languages will not be lumped together into a single universal language, but, keep being modernized and accepting new things from other languages, just like our own human languages do. We do accept new terms from other languages when our own language is not able to express certain concepts or when our language lacks words for certain things.

For one, when computers came to Brazil (I am brazilian) we "created" new words from their english counterparts, like, "to delete", which have a certain common root in latin, but was not used in modern portuguese. But, this wont make us use english words for ordinary things like traditional food or other common place items, because we have no reason to do so, that would be a futile use of effort to little gain. You might say that people should learn english to have better job prospects (like we usually think here) or to increase audience or something similar. But, in that case, people wont use english words in normal conversation.

So, this causes people to have two languages, not to forget their mother tongue or adapt it needlessly. This makes me believe that human languages will never (just like computer languages) converge into a single entity.

Answer 10

What programming (or other!) languages can't do is just as important as what they can do.

This already shows that there will always be something absolutely preventing one common language for everyone. For example, managed memory language programmers are quite happy to avoid having to deal with explicit memory allocation and deallocation - it means you can have more focus on things we can't automate yet (even in part). Lawyer-speak is very good when you're trying to be as specific as possible and with little possibilities for alternate interpretation.

Languages (again, programming or otherwise) are just tools. You choose the best tool for the job - sometimes it's a wrench, sometimes it's a jackhammer.

Now, you can obviously create a language that allows and disallows everything, for example based on some predetermined constructs or even compiler directives. For example, when I've been working on my C# OS, I actually had C# code that compiled into assembly-equivalents, something like:

registers.AX = memory.Indirect(variable1.Address); // Translated into mov ax, [EBP-20h]

(just pseudo-code, the actual code was a bit different - but it should illustrate the idea)

This actually allowed me to write all the code in C#, including the bootloader and device drivers.

The question is, does the fact that it's written in C# mean it's still just a single language called C#?

I'd argue no. In fact, a significant portion of the usual work of a programmer is creating his own languages. Not languages like C# or LISP, mind you - but rather, domain-specific languages to handle particular problems well, and nothing else. While those are always implemented in another particular language, they are a language of their own, a subset - just like English-lawyer-speak is a subset of Common-English.

Some languages lend themselves extremely well to such sub-languages - LISP/ML (and their derivates, like F# or Scala) being the prime example, of course. The interesting thing is that it's the strict languages that are the most useful for creating such sub-languages - whether the sub-languages are supposed to be strict or not.

So is there ever going to be one super language? Sure, why not. There's already plenty of candidates that got quite close - x86 was for a time almost universal, the original C had the target goal of being compilable anywhere (a lot of compilers still just produce code to be compiled for some C compiler). Or modern JVM-bytecode or IL. But that's about the level where I'd expect it to appear - intermediate. The end-user (-developer) level will be a nice little ecosystem of various languages well suited for their job - nothing less, nothing more. Unless of course you're planning for a dystopia where Apple-the-world-haegemon forces everyone to use Objective-C or something. Remember, it takes work to keep things simple - disorder arises quite naturally. There will always be disorder and disagreement, and they will both fuel plurality. Reducing complexity is the hard part.

Answer 11

No, there is not. It might be more easy to mix languages, but such languages are very formal and will not be blending on the conceptual framework level.

Perl comes close to being a natural language creole, but only among similar "types" of languages. You can't just mix in something that is built around more primitive memory manipulation, or toss in something that is purely functional. The general syntax style also can have variations but you can't toss in construct with a totally different kind of syntax.

Answer 12

Probably not.

As you have (correctly) stated there are many programming languages. Like speaking (natural) languages, they often borrow from each other. Unlike natural languages however, programming languages are guided by intelligent designers, aka programmers, who have their own (conflicting) ideas on 'whats best'.

As JDługosz points out, programming languages are always very formal. In a natural language, changes in speech patterns and pronunciation in an isolated group of people can result in different variants (US vs British English is a mild example). Not so in programming languages, a program is either in-spec or not. Changing the spec doesn't just happen, the compiler/interpreter writers must agree to a change that could break hundreds of programs that depend on particular behavior. If anything, programming languages are actually diverging because compiler/interpreter writers don't bother to stick to the language spec (see regex, there are: Perl, POSIX, emacs, vim, etc).

I also find it unlikely that programmers, generally being humans, will be able to agree on one single, all encompasing language. New ideas will always be integrated to keep languages modern, ideas are shared, but i find it unlikely that all programming languages will converge.

Answer 13

As compilers get increasing memory and cpu processing power, they can cope with being able to grab more and more source code languages. For example, gcc can usually compile-as ansi-c or c## as required, and can also compile as fortran F77 or a less old variant. What I'd expect is that human readable source code continues to append arbitrary user preferences and company preferences to known standards, and at times those may be unreadable to anyone else, but truly optimal executable machine code on a truly arbitrary RISC processor probably will converge as much as possible.

One day source code might have been abstracted behind high level instructions so much that it might be possible to stand in front of your MakeAnythingBot and say "Computer, design and make a space programme, a monetary system, an agricultural production system, all necessary materials supplies, and an improved MakeAnyThingBot", and it will. Should that happen, we are in big trouble, I think.

Answer 14

tldr I believe programming languages are going to converge simply because there are too many ways for it to happen.

Let's hit some of the highlights of the (somewhat) short history of programming.

• Switches
• Punch cards
• Assembly language
• Interpreted/scripting languages
• High level languages
• Object oriented languages
• "Managed" languages

In only 70-ish years we have moved from switches and cranks to incredibly efficient compilers with both syntax and semantic checking. In one or two hundred years from now I can't even imagine how we will be programming (if we even are) but I will venture some guesses.

Most of the answers here are making an implicit assumption for continued use of the Von Neumann architecture that is for all practical purposes the only architecture that currently exists. But to discount a different architecture, especially when optical or quantum computers come into being, is short sighted.

All the "reasons" given that a single language is untenable simply highlight the disadvantages of our current computing architecture. They do not address any future progress in this area. To say that in 100 years we will still be using a Von Neumann architecture is highly speculative.

So how can we get to one language?

We were actually on track for Java to become our 'one' language when the 'java chip' was being developed. It understood Java byte-code natively - there would be no need to have any but one language if every computer used the 'java chip'. And for web programming we could have used a subset of the language to work within browsers. There is nothing that (technically) prevents us from using a single language now. We could have written browsers to use C or C++ and just redacted some of the commands from the language, like file access for example.

If we change architectures then one language may be the inevitable and obvious choice.

We may get to the point of simply speaking what we want the computer to do and it understands what we mean - natural language programming. The new computer 'language' will be whatever we program the computer programmer to use. And there's no reason to have 10 'high level' languages for it to choose from.

And what about neural implants? Perhaps we will just 'think' what we want to do.

And perhaps in the future we won't even program at all. An artificial Intelligence will simply build machines, grow food and cater to our every need like in the animated movie WALL-E. Hopefully we won't just become sedentary like that and will instead be artists, musicians, etc.

Planes were invented 112 years ago, rockets made it to orbit 30 years later, to the moon 20 years later, a man on the moon 17 years later (about the time C was invented) which was only 46 years ago. To Venus the next year and then Mars the next year. To say programming will be anything like it is now in 200 years or more defies history.

Is this too far out there? For some people, yes. But technology is advancing so fast that to deny any of these scenarios out of hand is ignoring our potential as a species.

Answer 15

As many others pointed out, different programming languages have different fields of usage, so probably no. And I agree with that.

But I want to add some other perspective. Computing is young. The first programming language was Plankalkül from Konrad Zuse developed between 1942 and 1945. Thats 70 years ago. People from that time are still alive. But that were the early baby steps, computing reached no masses back then.

It really kicked off later, so I would assume the first programming language with broad reach was ALGOL, from 1958. That's a little more than 55 years ago. This language is out of usage, no questions on Stack Overflow this year, only three last year; I think we can safely assume it's dead by now.

So let's look a bit further. COBOL was released 1959. 88 questions this year already on Stack Overflow show that this language is still in usage. We talk about a language that a Dilbert-comic nearly 20 years ago already showed as fossil:

Even C is pretty old already, and it is one of the most popular languages around.

So what's happening here? As I said, computing is pretty young. If a new language needs 5 years to get popular and stays popular for 5 years, and youngsters learn it when it's popular at say average 25 years and then work until they are 65 - then you can see that it brings at least 50 years of lifetime to a language that becomes popular. The only ones that died earlier are languages that never get popular to begin with. And this time is extended, if there is a big codebase to maintain in that language, that was created in the time the language was popular. This is one of the reasons C is still that much in usage and a reason why I think Java will be programmed even in eons from now.

So, as computing is pretty young, we are still in a phase in which more languages are created than ones that fall out of usage. That probably will settle sometime, but I don't see reasons why the development of new languages will ever stop. So no, looking from a historical standpoint on the longetivity of languages, there will probably never be only one.

Answer 16

This question needs to be addressed in terms of limits, otherwise its just a programmers talking shop. Since the timescale of centuries was mentioned, looking at the limit case is valid.

In the limit, all matter in the solar system has been converted to computronium by nanomachines and all that computronium is arrayed around the sun to harvest the maximum possible energy.

At this far removed stage the underlying hardware architecture is probably quite homogenous - even today we see signs of convergence of hardware architecture - most specifically in terms of high speed serial communications (PCI 4.0, 100 GBE, USB3.0 - under the hood they are all very close in terms of electrical properties and link layer protocols whereas once they were quite diverse). People get fixated on computer science in terms of instruction sets and languages rather than what really matters - both today and in my far limit scenario which is the thermodynamic costs of moving data from A to B. Once the data has moved the cost and specifics of processing it is secondary.

As processing power improves and as the distances data must move to be processed increases, information processing becomes mostly a thermodynamic accounting circumscribed by shannons laws and fundamental physics.

As that reality progresses and becomes more apparent then the advantages that can be obtained by using this abstraction or that will diminish and the language wars will end and be supplanted by mathematics and maximally efficient version control protocols that allow meaningful semantic processing to occur even when the time it takes data to reach from A to B is very large compared to how fast the receiving entity could evolve, if it chose to.

If all hardware architecture ends up the same, then the universal language is the language in which that hardware is programmed at the lowest level of programmability. Language abstractions built on top of that probably don't qualify as languages in the same way we would not think of scientific terminology recounted in the english language as being a distinct language from english itself.

Finally, if the hardware (computronium) is itself reconfigurable (no doubt for a non trivial thermodynamic cost) then the concepts of software and hardware don't have a lot of meaning. In fact both would reduce to the same thermodynamic principles, although version control (which at this level can only try and keep genuinely irreversible processes separate from reversible ones) may have some independant role to play.

Obviously this scenario is some way off but placing a storyline at some point on this trajectory is IMO a valid hard sci-fi approach.

Answer 17

Overall, no - for all the reasons specified, however it is likely we will develop a universal descriptor language for programs/features that is both understandable by humans and the dedicated expert systems which use them to write basic applications. See Natural Language Processing.

For instance we could say "I would like an application that collects, archives and displays weather data for my region." The expert system would interpret this and write an effectively throw-away module that performs that function (with some insight into your personal GUI preferences through analysis of your profile or dynamically generated based on the style preferences of the terminal you're viewing the application on).

Naturally the description of a game would be very lengthy and graphically challenging but by splitting the description into features and levels this could actually be accomplished. The descriptor language - whatever that might turn out to be would be structured to deal with those tasks.

Answer 18

There are plenty of reasons listed above that there will never be a One True Language. However, it is entirely within the realm of possibility that one create a mega-language which, at its core, is a bunch of DSLs.

All the languages would have to use the same runtime or virtual machine, and there would have to be some sort of namespace standardization. Once you have that, you can have:

• A plain imperative programming language for when you want to say, "Do this, then this, and then this"

• A true Object-oriented language, for encapsulation and similar things

• A functional programming language with no non-functional "leaks" (not so much as a print statement) so that you could guarantee the isolation of a piece of code

• A relational language, maybe even a flavor of SQL, so that it could be a first-class language rather than a list of strings which can't be checked at compile-time

• A declarative language similar to Make or Prolog

• A first-class regular expression language, so you don't have to write code that looks like line noise

• Proper parsers -- something like Lex and YACC which don't compile into C, but become first-class language constructs in their own right.

• A software build system language -- something like Maven or Ant or such.

It still wouldn't be the One True Language--something that big would probably need to be implemented in something simpler (C strikes again!). However, one could go far with that. Learning it wouldn't have to be much (if any) harder than learning one language today, because each language could afford to be incomplete. For example, no language except the Regular Expression language would have to have Regular Expression functionality. The declarative language wouldn't need to be able to run imperative code just to be useful. The imperative language can be simple, as it doesn't have to support every programming paradigm under the sun.

Answer 19

As a short answer, computer languages are written with syntax and semantics to solve problems. I am sure that, if the scope of problems computer programming is being asked to solve were to remain constant, we would find languages converging rather rapidly.

However, finding anyone who thinks the scope of computer programming is remaining constant, or for that matter, anyone who thinks the scope of computer programming is doing anything besides an unbridled sprint into the future, that could be difficult.

Answer 20

Going by Microsoft's way, "Use your own language in .NET framework" theorem, it started with about 26 languages and is now about 146 languages and growing. And every one of them evolving with new hardware trends. Programming languages only matured not dropped.

Going by Java way "Forget everything learn only Java". I'm not very sure on current status while Java has moved from Sun to Oracle/IBM,...and so on losing main objective of portability slowly.

Unlike human languages, PC languages should evolve and new ones should be added. We had 'C/Fortran' based and 'Basic' based. Then Scheme based. So it is about the programmer which flavor he/she likes.

My personal language of appeal is VB and it has always solved what I required. Most importantly on a long later period, the code is as good as normal English to read and understand and yet compiled into high efficiency binaries.

Let new programming languages evolve so new methodologies can come up. Lets not restrict in the name of convergence please.