3 ms·

My C code from last century fails to compile due to changes in "more secure function definitions". C++ changes "the standard" every couple years. When someone

by daly 4y ago

My C code from last century fails to compile due to changes in "more secure function definitions". C++ changes "the standard" every couple years. When someone tells me they "know" C++ I have to ask which "standard" they "know". Common Lisp code I wrote in the last century runs unchanged today. So the complaint about Common Lisp being stuck in the past is actually a feature, not a bug. When Julia settles on a standard (and only one standard) then it will be worth the learning investment. When that happens I can write code that will run without change in 2070.

mrtranscendence 4y ago
So learning a programming language would be worth the investment only if that language has one unchanging standard? That feels to me like a bit of a hot take. Almost everything else changes in the world, often by necessity, so it's unclear to me that it's worth ossifying implementations so that C code from 1990 easily compiles in 2022.
- daly 4y ago
  A large portion of my (non-lisp) time is taken up because someone changed a language. What used to compile no longer does. Take, for example, Python. A large codebase in 2.7 needs to be ported to Python3 because a customer has a Python3 library. The original problem now needs to be re-coded by people who did not write the original code, achieving nothing of value. Of course, some of the Python 2.7 libraries need to be re-written without access to the source. The goal for a 'standard' is not ossifying a language. Don't pretend that Python3 is in any way related to Python. Call it Snake or something else. Then 'python' code continues to work and 'snake' continues to work. The confusion, especially evident in C++, is that 'C++' is at least half-a-dozen languages related by chance. When asked if you know C++, you really should reply with the 'standard' that you claim to know. There are 6 C++ "standards" that I'm aware of. I understand there is a 7th due to arrive in 2023. I wonder if 'concepts' will be in the new 'standard'. If so, do you know what it means to inherit 'up the add chain' versus regular inheritance? If not, can you still claim to 'know C++'? It takes a LONG time to get "command of a language". Reading other people's code is a great way to see how much you don't know. For example, did you know that in C++ you can dynamically create a class and an instance IN THE ARGUMENT LIST OF A FUNCTION? It can take years to really "know" a language, much longer than the change time of languages.

by daly 4y ago

mrtranscendence 4y ago

So learning a programming language would be worth the investment only if that language has one unchanging standard? That feels to me like a bit of a hot take. Almost everything else changes in the world, often by necessity, so it's unclear to me that it's worth ossifying implementations so that C code from 1990 easily compiles in 2022.

daly 4y ago
A large portion of my (non-lisp) time is taken up because someone changed a language. What used to compile no longer does. Take, for example, Python. A large codebase in 2.7 needs to be ported to Python3 because a customer has a Python3 library. The original problem now needs to be re-coded by people who did not write the original code, achieving nothing of value. Of course, some of the Python 2.7 libraries need to be re-written without access to the source. The goal for a 'standard' is not ossifying a language. Don't pretend that Python3 is in any way related to Python. Call it Snake or something else. Then 'python' code continues to work and 'snake' continues to work. The confusion, especially evident in C++, is that 'C++' is at least half-a-dozen languages related by chance. When asked if you know C++, you really should reply with the 'standard' that you claim to know. There are 6 C++ "standards" that I'm aware of. I understand there is a 7th due to arrive in 2023. I wonder if 'concepts' will be in the new 'standard'. If so, do you know what it means to inherit 'up the add chain' versus regular inheritance? If not, can you still claim to 'know C++'? It takes a LONG time to get "command of a language". Reading other people's code is a great way to see how much you don't know. For example, did you know that in C++ you can dynamically create a class and an instance IN THE ARGUMENT LIST OF A FUNCTION? It can take years to really "know" a language, much longer than the change time of languages.