It makes sense when you parse "sooner or later" in the way people use it outside the technological domain:
- Sooner or later we'll go back to the moon.
- Sooner or later we'll understand how the brain works.
- Sooner or later the earth will crumble to dust.
...and so on.
But seriously, we've only been programming for 50 years now. There's still plenty of time for some revolutions and paradigm-shifting—just because the Mythical Man-Month has been heart-rendingly applicable for the last 50 years, doesn't mean that things can't change.
For example:
1. If everyone agrees to target some highish-level bytecode or another, every language will basically have access to every other language's libraries (let's hope it doesn't end up being the JVM, though things seem to be heading there.)
2. If we stick content hashes in function and class names, there will no longer be such a thing as API versioning conflicts, because you'll always know what you're calling—and you can just import random code from remote sites (i.e. invoking on a URL as an identifier = loading whatever bytecode is available at that URL), because you'll just hash it and guarantee that it matches its name before jumping to it.
3. If we can stop requiring that the source code we write be exactly the same source code the compiler parses, we can treat code files as a serialization format for an AST data structure (in XML or SEXPs if you want to keep the source-source human-readable), and work with it however we like in an IDE, even "rendering" it as one old-style-"language" or another.
And so on. These are problems that just need to overcome 20 or 30 years of inertia, and, ever-so-slowly, we're doing it.
So true. Not so long ago, we thought that using natural-language-like text can enable non-programmers to work with code... (and then did it again with rules engines (and we'll do it again at some point in the future)).
Re. 2: didn't we go through this when SOA and SOAP were all the best thing since sliced bread? The problem with APIs is not with versioning per se (if want to use URIs, just stick version number in the first position, webservices do that) - it's about what happens to dependencies. You have to call v5, you've got v1..v8 available, but another library you use talks to v3. Can you share objects? How is the v8-compatible state affected when v5 and v3 are doing the work? Which api is called when in your v5 area you call a method on a v3 object?
Re. 3: Yeah... I was considering tackling that for my degree at some point. The source file is just a placeholder that can contain some string generating new placeholders - why don't we simply start working on it that way?
Combine 1, 2, and 3, and you can make the function name just the content hash (of its AST, not its string representation)—the name becomes metadata. Every function call, then, just refers to another hash, which the loader (or the linker, if you want to inline for performance) just Googles and uses the first result that hashes right. Basically, all libraries become one library—called the Internet. Or, to put it alternately, every function, protocol, and data structure would be versioned inividually, as if they were all files stored on a Git repository.
As I read around, the JVM seems to be the state of the art for language runtimes. Can you elaborate why you hope it will not be the unified one in the future? Just curious.
What the JVM has going for it is the incredible amount of resources thrown at it in order to make it fast. Technically, the CLR seems more interesting (it has runtime type information for generics, it allows structs, it allows unboxed data, ...).
Personally, I'm not a fan of runtimes. They don't give me the same warm, fuzzy feeling as compiling to native code and running directly on the OS.
Are you sure all of these makes the CLR more interesting? One can argue some of it just makes it more complicated. Real generics, I agree about, but structs and unboxed data? I am not sure that implementing these instead of investing time in making the compiler & runtime smarter is the thing to do.
- Sooner or later we'll go back to the moon.
- Sooner or later we'll understand how the brain works.
- Sooner or later the earth will crumble to dust.
...and so on.
But seriously, we've only been programming for 50 years now. There's still plenty of time for some revolutions and paradigm-shifting—just because the Mythical Man-Month has been heart-rendingly applicable for the last 50 years, doesn't mean that things can't change.
For example:
1. If everyone agrees to target some highish-level bytecode or another, every language will basically have access to every other language's libraries (let's hope it doesn't end up being the JVM, though things seem to be heading there.)
2. If we stick content hashes in function and class names, there will no longer be such a thing as API versioning conflicts, because you'll always know what you're calling—and you can just import random code from remote sites (i.e. invoking on a URL as an identifier = loading whatever bytecode is available at that URL), because you'll just hash it and guarantee that it matches its name before jumping to it.
3. If we can stop requiring that the source code we write be exactly the same source code the compiler parses, we can treat code files as a serialization format for an AST data structure (in XML or SEXPs if you want to keep the source-source human-readable), and work with it however we like in an IDE, even "rendering" it as one old-style-"language" or another.
And so on. These are problems that just need to overcome 20 or 30 years of inertia, and, ever-so-slowly, we're doing it.