Perhaps, but you could turn it around, too.
Statically typed languages had time to catch up because innovation into "more powerful/better language mechanisms" has stalled, for some other reasons.
Perhaps, but you could turn it around, too.
Statically typed languages had time to catch up because innovation into "more powerful/better language mechanisms" has stalled, for some other reasons.
innovation into "more powerful/better
language mechanisms" has stalled, for
some other reasons.
For sequential languages there is probably not much to improve -- except at the edges. ML nailed it. Almost all core PL research today is about- verification
- concurrency/parallelism
because both are beset with deep unsolved problems: for verification the problem is how to do it efficiently (we know we can do it in principle), and for concurrency/parallelism we have not yet discovered core abstractions including the right types that can express simple properties of concurrency/parallelism (at least that is my working hypothesis). This is intimately related to our current inability to auto-parallelise.
And that's the problem right there. There is sooo much that is out of whack with programming, even sequential.
For starters look up 'architectural mismatch'.
So, there's not so much a problem in programming languages with architecture so much as programmers ignoring proven ways of catching such problems. Usually what I just mentioned plus review and testing. People like hwayne are laying groundwork for reductions in this problem by making accessible tutorials showing practical value of such techniques.
Then why does Haskell exist? And if Haskell nailed it, why does the Backpack module system exist?
Clearly, nobody has "nailed it".