I think the "problem" you describe will get worse, not better. Software will get more fractured indefinitely; I believe it's an economic inevitability. There is plenty of old code that works and nobody has the time or knowledge to rewrite it.
Go isn't going to replace Python; you'll have Go AND Python. Moreover you'll have Python 2 and Python 3, and perhaps Go 1 and Go 2. Julia won't replace R or Matlab; you'll have all 3.
You're basically advocating a modernist view, which I hear a lot of programmers espouse. I think this is confusing what you want to happen with what will happen.
A more accurate picture of the future of software is something like Richard Gabriel's "Design Beyond Human Abilities". It's long so I won't try to summarize it, but it paints a unique picture, and I think an accurate one.
We are going to build greater and greater things, but they will be more balkanized and full of conflicting forces. They will look a little more like the evolved human body than a perfect crystal.
I think the deep wisdom of Unix goes a long way toward easing the pain. Text is the lowest common denominator; it bridges the gap between all these conflicting systems. There will be no universal model; only localized models and subcultures that talk to each other through sloppy protocols.
You're probably right. Something like Urbit[1] is more a romantic notion than a way forward—people won't give up the many for the one.
Still, though, I'm heartened by the Unified Theory Of Gradual Protocol Ossification—this being the idea that, even though we've ratcheted up from computer networks speaking any kind of IP-based transport protocol to only being able to speak TCP, and then in some places only being able to speak HTTP over TCP—that what this really implies is that HTTP is commoditizing the transport layer, and that, as soon as the abstraction is airtight—which it seems increasingly to be with HTTP2—we'll be able to just sweep the redundancy under the rug by replacing the IP+TCP+HTTP2 mess with a single cleaned-up protocol that presents the same abstraction.
In this case, I imagine that the way forward is meta-languages that are effectively DSLs targeting multiple abstract machines, allowing you to mix-and-match semantics in isolated subsets of your programs, and resulting in mixed-target code generation. Once people are on that abstraction—where "language" is not 1:1 with "abstract machine", and "abstract machine" is not 1:1 with deployment platform—then we can come along and sweep the redundancy under the rug.
Huh? It sounds like you're engaging in the same kind of wishful thinking about HTTP2 now, rather than programming languages. What you are describing will never happen.
Go isn't going to replace Python; you'll have Go AND Python. Moreover you'll have Python 2 and Python 3, and perhaps Go 1 and Go 2. Julia won't replace R or Matlab; you'll have all 3.
You're basically advocating a modernist view, which I hear a lot of programmers espouse. I think this is confusing what you want to happen with what will happen.
A more accurate picture of the future of software is something like Richard Gabriel's "Design Beyond Human Abilities". It's long so I won't try to summarize it, but it paints a unique picture, and I think an accurate one.
https://scholar.google.com/scholar?cluster=53971620417639306...
We are going to build greater and greater things, but they will be more balkanized and full of conflicting forces. They will look a little more like the evolved human body than a perfect crystal.
I think the deep wisdom of Unix goes a long way toward easing the pain. Text is the lowest common denominator; it bridges the gap between all these conflicting systems. There will be no universal model; only localized models and subcultures that talk to each other through sloppy protocols.