4 ms·

"John W. Backus suggested to IBM a language to replace assembly language." And today, in a world with far more CPU homogeneity, we have an endless stream of ne

"John W. Backus suggested to IBM a language to replace assembly language." And today, in a world with far more CPU homogeneity, we have an endless stream of nerds suggesting to HN languages to "replace" C. I am never sure what "replace" means when used in this context. I'm still using assembly language; other languages cannot match it. In the same way, FORTRAN is still being used. Perhaps "supplement" should be substituted for "replace". Enduring fact: "Your Father's" languages are more performant than the new ones you hold in high regard. Because performance will always be important to some people, I doubt these old languages will ever disappear from use. Unless someone can construct a compiler that accepts a different "language" and produces more performant object code, these languages will never be "replaced".

lucozade 11y ago
> I am never sure what "replace" means when used in this context It means the use of assembly is replaced with the use of Fortran. At which it was very successful in scientific computing. I don't believe it was ever meant to mean exterminate. Bear in mind that all programming was done in assembly or machine code prior to the introduction of Fortran. Since then a relatively tiny (though important) proportion of programmers program in assembly. That was the intent and it worked swimmingly. And only masochists program in machine code.
ThatGeoGuy 11y ago
> 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.

lucozade 11y ago

> I am never sure what "replace" means when used in this context It means the use of assembly is replaced with the use of Fortran. At which it was very successful in scientific computing. I don't believe it was ever meant to mean exterminate. Bear in mind that all programming was done in assembly or machine code prior to the introduction of Fortran. Since then a relatively tiny (though important) proportion of programmers program in assembly. That was the intent and it worked swimmingly. And only masochists program in machine code.

ThatGeoGuy 11y ago

> 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.