4 ms·

Throughout my career I've only grown a monotonically increasing level of appreciation and support for backwards compatibility. It seems to be an ever-increasing

by jerf 3y ago

Throughout my career I've only grown a monotonically increasing level of appreciation and support for backwards compatibility. It seems to be an ever-increasing problem, because as we solve a lot of the other problems around using libraries, this one gets bigger and bigger. However, I don't know how things are actually supposed to advance in such an environment. At the programming language level, my answer is, develop new languages. Existing languages should not klunk along and keep adding feature after feature trying to chase the state of the world 20-30 years after they were initially designed. But even if you accept that statement from me, which I know many of you won't and I'm OK with that, that's still not a very big help anyhow. I don't have a language I'm maintaining, and neither do most of you. I have some apps and libraries. What am I supposed to do with them as deficiencies in their underlying foundation are revealed? To which I simply don't have an answer. My little team has two UIs we've inherited, both in super deprecated languages or UI frameworks that we can barely work on anymore, but we can't afford to be rewriting them every four years. A nontrivial part of the reason they're still staring at us is that we're reluctant to put a lot of time into upgrading them, only to discover 2-4 years later that we upgraded one obsolete stack we can't actually change anymore into another obsolete stack we can't change without a rewrite. The only thing I can say is that I can see the programming world coming to a greater understanding every year that every dependency is a bigger long-term cost than meets the eye, and all I can say is thumbs up to that and it's something we need to continue to appreciate collectively. It isn't a solution, but at least it leads to actions that are little improvements, and lots of little improvements are still better than nothing.

tialaramex 3y ago
> However, I don't know how things are actually supposed to advance in such an environment. Gradually. Rust has lots of examples of this, but look at std::mem::uninitialized::<Thing>() https://doc.rust-lang.org/std/mem/fn.uninitialized.html https://doc.rust-lang.org/std/mem/fn.uninitialized.html -- back in 2015 the assumption was, OK, surely so I mark this memory as a Thing, and then I scribble over the values in memory so that it makes sense as an actual Thing and we're all good. Right? Wrong. That's actually definitely nonsense, In 1.36 Rust got a type to do this properly, std::mem::MaybeUninit<Thing> now we say OK, this memory might be a Thing, but, for now it's just uninitialized. Then we scribble over whatever is necessary to make a Thing, and then we call MaybeUninit::assume_init() to promise that this is a Thing now. That's type correct, the compiler won't get confused and assume it's a Thing until it really is a Thing. In 1.39 Rust deprecated std::mem::uninitialized() But, if you wrote code back then and never updated it, your code is not worse than it was back then, you don't need to rewrite it (though if it uses this deprecated function you should consider doing so) it's just now indirectly calling MaybeUninit::uninit() then doing some best efforts work to tell the compiler please don't hurt this programmer, and then MaybeUninit::assume_init() to get the result you asked for even though that might be a bad idea, it is what you asked for.
deleted 3y ago
[deleted]
lenkite 3y ago
Languages need to break stuff once every X years or they will die. Witness C++ - which is currently undergoing a death spiral. Thanks to perma ABI and language compatibility, even genius level people are finding it impossible to create workable language/stdlib improvements. There is always an edge case that breaks compatibility which is un-acceptable. Most folks just give up after the Nth rejection of their feature proposal. And performance of many components of the standard library is now laughable. C++ std::regex is slower than most interpreted language regex libraries. It is utterly embarrassing for a language that prides itself on performance. This keep-it-backward-compatible till the heat death of the universe attitude of the standards committee is causing folks to create several successor languages that transpile to C++ - or just move to Rust. Its the perfect example of how adherence to backward compatibility over everything else in a language is just effective suicide.
- pjmlp 3y ago
  Some of the issues regarding ABI are caused by compiler vendors themselves, ISO C++, just like ISO C, has zero content on ABI. Same applies to stuff like std::regex, compiler vendors are the ones to blame. In any case, there is plenty of C++98 code that won't compile in C++23, because even ISO C++ does break backwards compatibility.
- jerf 3y ago
  C++'s problem isn't that it stopped breaking stuff. C++'s problem, or as I like to call it, Katamari Dama-C++, is that it needed to freeze a long time ago and they just needed to build a new language. They're exactly who I am thinking of in terms of just making a new language. By language scales, Rust is exploding on to the scene and eating C++'s lunch precisely because they won't stop mucking with it. You might say that in absolute terms Rust is still not that much code and that's true, but in terms of how languages tend to turn over Rust is blowing C++ away. Much faster than the usual such process. There are other languages that just need to accept that they are what they are and that endlessly adding features is only making their situation worse. Looking at you, Python. The community should just have accepted that Python can not be multithreaded and it doesn't have a good async solution, and people who needed these things should have started moving to other languages for solutions to those problems, instead of accreting an ever-increasing bunch of features flailing about trying to solve these deep, fundamental problems, and convincing a whole bunch of people that if they just hang on for another year, 3 years, 5 years, maybe a bit longer, Python will someday solve their problem. Now they're years into that process and they'd have been better off just switching years ago instead of being on an increasingly complicated language, and Python would have been better off being a good Python instead of trying to chase the kids.
p0nce 3y ago
> To which I simply don't have an answer. D does it with gradual deprecation, and not too much at once, it is the best for deprecating stuff (you don't need to fix your code immediately) but there is always a residual complaining from people that assume there will be no work to maintain software. In reality someone maintain your compiler/runtime, and their needs are part of your stack.

by jerf 3y ago

tialaramex 3y ago

> However, I don't know how things are actually supposed to advance in such an environment. Gradually. Rust has lots of examples of this, but look at std::mem::uninitialized::<Thing>() https://doc.rust-lang.org/std/mem/fn.uninitialized.html https://doc.rust-lang.org/std/mem/fn.uninitialized.html -- back in 2015 the assumption was, OK, surely so I mark this memory as a Thing, and then I scribble over the values in memory so that it makes sense as an actual Thing and we're all good. Right? Wrong. That's actually definitely nonsense, In 1.36 Rust got a type to do this properly, std::mem::MaybeUninit<Thing> now we say OK, this memory might be a Thing, but, for now it's just uninitialized. Then we scribble over whatever is necessary to make a Thing, and then we call MaybeUninit::assume_init() to promise that this is a Thing now. That's type correct, the compiler won't get confused and assume it's a Thing until it really is a Thing. In 1.39 Rust deprecated std::mem::uninitialized() But, if you wrote code back then and never updated it, your code is not worse than it was back then, you don't need to rewrite it (though if it uses this deprecated function you should consider doing so) it's just now indirectly calling MaybeUninit::uninit() then doing some best efforts work to tell the compiler please don't hurt this programmer, and then MaybeUninit::assume_init() to get the result you asked for even though that might be a bad idea, it is what you asked for.

deleted 3y ago

[deleted]

lenkite 3y ago

Languages need to break stuff once every X years or they will die. Witness C++ - which is currently undergoing a death spiral. Thanks to perma ABI and language compatibility, even genius level people are finding it impossible to create workable language/stdlib improvements. There is always an edge case that breaks compatibility which is un-acceptable. Most folks just give up after the Nth rejection of their feature proposal. And performance of many components of the standard library is now laughable. C++ std::regex is slower than most interpreted language regex libraries. It is utterly embarrassing for a language that prides itself on performance. This keep-it-backward-compatible till the heat death of the universe attitude of the standards committee is causing folks to create several successor languages that transpile to C++ - or just move to Rust. Its the perfect example of how adherence to backward compatibility over everything else in a language is just effective suicide.

pjmlp 3y ago
Some of the issues regarding ABI are caused by compiler vendors themselves, ISO C++, just like ISO C, has zero content on ABI. Same applies to stuff like std::regex, compiler vendors are the ones to blame. In any case, there is plenty of C++98 code that won't compile in C++23, because even ISO C++ does break backwards compatibility.
jerf 3y ago
C++'s problem isn't that it stopped breaking stuff. C++'s problem, or as I like to call it, Katamari Dama-C++, is that it needed to freeze a long time ago and they just needed to build a new language. They're exactly who I am thinking of in terms of just making a new language. By language scales, Rust is exploding on to the scene and eating C++'s lunch precisely because they won't stop mucking with it. You might say that in absolute terms Rust is still not that much code and that's true, but in terms of how languages tend to turn over Rust is blowing C++ away. Much faster than the usual such process. There are other languages that just need to accept that they are what they are and that endlessly adding features is only making their situation worse. Looking at you, Python. The community should just have accepted that Python can not be multithreaded and it doesn't have a good async solution, and people who needed these things should have started moving to other languages for solutions to those problems, instead of accreting an ever-increasing bunch of features flailing about trying to solve these deep, fundamental problems, and convincing a whole bunch of people that if they just hang on for another year, 3 years, 5 years, maybe a bit longer, Python will someday solve their problem. Now they're years into that process and they'd have been better off just switching years ago instead of being on an increasingly complicated language, and Python would have been better off being a good Python instead of trying to chase the kids.

p0nce 3y ago

> To which I simply don't have an answer. D does it with gradual deprecation, and not too much at once, it is the best for deprecating stuff (you don't need to fix your code immediately) but there is always a residual complaining from people that assume there will be no work to maintain software. In reality someone maintain your compiler/runtime, and their needs are part of your stack.