Is there a reason to believe that programming languages are going to converge?
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?
This post was sourced from https://worldbuilding.stackexchange.com/q/17828. It is licensed under CC BY-SA 3.0.
2 answers
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.
0 comment threads
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.
0 comment threads
0 comment threads