> Enduring fact: "Your Father's" languages are more performant than the new ones you hold in high regard. I don't know if I buy this. Common Lisp and even to a

> Enduring fact: "Your Father's" languages are more performant than the new ones you hold in high regard. I don't know if I buy this. Common Lisp and even to an extent Scheme as we know them today are much faster than the MacLisp of many decades ago. Sure, we're not replacing FORTRAN or C with Python or Ruby, but I think it's disingenuous to say that we haven't gotten better at optimizing newer languages. Even in that same token, C and FORTRAN have changed significantly since the 80's, and C11 hardly looks anything like what C used to be. Further to the original point, we have Javascript VMs that are incredibly high-performance. Even more-so, C++ wasn't even around at the time of FORTRAN, does that still count as my father's language? I wouldn't say so, and in summary, I don't think performance is the reason we hold on to old languages. Back to your original point about "replacing" languages: I think you're speaking too broadly. For example, nobody in the high-performance-computing space will likely replace FORTRAN or C for tight mathematical operations, especially when large datasets are involved. However, in the general case, I'd say that FORTRAN and C have been replaced in a lot of other industries. This is especially so in industries where exact hand-written assembly or low-level C don't make sense for the 98%+ of cases. Nobody in their right mind would write scientific computing software in pure assembly. Even if you argue that most of the heavy lifting in Python+Numpy or MATLAB or Julia comes from C libraries, you don't typically interact with the underlying C or FORTRAN from day to day. In many ways, we've replaced C and FORTRAN, even if they're not gone from the annals of history. And given how long software sticks around (even once we've tried killing it), they likely will not be eradicated for a long time. The point, then, is that replacing these languages is just a means to give us better abstractions so we don't have to think on the terms of older languages. There's been a lot of expressiveness gained from language research that have benefited humanity in immeasurable ways. >Unless someone can construct a compiler that accepts a different "language" and produces more performant object code, these languages will never be "replaced". I hate to bring it up, but Rust, asm.js, and other low-level projects (Julia / Nim anyone?) are already aiming towards this goal for specific use-cases. I will admit that they are not fully there (sans Rust which already compiles with decent performance), but they will come.