I just want to reply to almost every suggestion on this page that we've tried that, numerous times. Most suggestions here need not to explain why the suggestion is wonderful, but why it is that previous efforts to implement the suggestion didn't take the world by storm if they were so wonderful.

That extends to probably about half of the linked paper, as well, though I daresay it fares better than most I've seen.

I think we've mostly mined out the thoughts of the past, running on machines essentially simulating the machines of the past. All the bright ideas people had fifty years ago but had no prayer of getting to work on the hardware of the time has had time to be tried out. While I'm sure there is some path dependency in our current best practices, I personally think it's easy to overestimate it. There's a lot of languages running around, and if something was really 10 times better, I think we'd notice.

I think the next step up is going to require new thoughts, mostly driven by taking a fresh look at the hardware we have now and reconsidering the way we currently lay down a ~1970s paradigm on top of whatever hardware we get. It may also require some new hardware to be developed, as we stall out at current clock speeds. I don't know exactly what it will look like, but, well, first of all I see multiple languages, not one grand one, but languages like...

... something natively built to deal with hetereogeneous execution on GPU, CPU, slow-but-efficient-CPU, FPGA, and so on.

... something that successfully wraps up the sort of work that Haskell has been pioneering and moves us beyond working with ints and strings to something higher; an integrated view of functors and other higher structures, probably wrapped up behind friendly names, and using that to work with parallelism appropriately. There's a sense in which it's weird that it's 2019 and I'm still getting slabs of 32 bits to hold numbers, and the semantics of this hasn't hardly changed.

... Rust arguably already fits in here, but more efforts to pull down work done on the fringes of safety into something that people can actually use to build high-performance, yet safe, systems. These languages may not be 10x development speed improvements at the local level, but they can accelerate large projects by making a lot of things safe to do that right now are terrifying on a large code base. In general I still feel there's a lot of work to be done in the field of large programs. A lot of up-and-coming programming languages are still way too focused on making individual lines powerful, because that's cool, or because it's easy to evaluate how a new proposed feature does or does not make a 3-statement snippet now become one, but neglect how to make big programs hold together safely and without the whole thing calcifying to the point you can't move it forward as time goes on.

... as a specific case, languages or libraries designed to deal with the burgeoning field of "what can we safely do over a network", via CRDTs, lattices, and other safe mechanisms, integrated into the entire language's outlook rather than being a bodged-on addition.

... languages like Jai that detach the operational semantics of a data type from its storage, so that I can create an array of structs and just tell that array to actually be a struct of arrays, and maybe compress the array data if I'm willing to guarantee I'm always going to go sequentially across this array, etc., or tell it my access pattern so it can store the array optimally, using our modern hardware more efficiently than pretending it's still 1970 and memory accesses are all the same cost. Maybe throw in some cache awareness, or a pervasive cache-obliviousness, again at the language level if possible.

One thing I do not see, for what it's worth, is an increase in the declarative nature of programming languages. I don't particularly believe in declarative languages anyhow, but a lot of these things involve giving the programmers the ability to say more than current languages let them say, not less.

Many of these can work together harmoniously; safety, "something something CRDTs lattices", and data structures that integrate higher-order safety characteristics like functor and monad probably all go together pretty well. A language to address heterogeneity in computation might just work well on a network computer, too.