6 ms·

And this is how backwards compatibility comes to kill innovation. It's a reasonable stance to keep supporting your long established users but it comes at the co

And this is how backwards compatibility comes to kill innovation. It's a reasonable stance to keep supporting your long established users but it comes at the cost of ceding the future to the competition (cough Rust cough)

schemy 6y ago
Rust is the future and always will be.
- deleted 6y ago
  [deleted]
mytailorisrich 6y ago
IMHO that's how it should be for a programming language. If a programming language evolves to the point that previous programs written in that language no longer compile then it's no longer the same language. So let's keep C as C and, as you point out, new ideas and concepts that would break things can be implemented in new languages. C does evolve but it's also taken the pragmatic approach not to break the huge existing code base it has. In many cases these programs have been running for decades, they work.
- Tehnix 6y ago
  >If a programming language evolves to the point that previous programs written in that language no longer compile then it's no longer the same language. I don't really buy that you cannot ever introduce breaking changes. That's a recipe for disaster and IMHO short-sighted. >In many cases these programs have been running for decades, they work. And in many other cases, they have been full of security holes that take an incredible amount of work to discover. Something like Rust's editions seems to solve this problem very well, and is indeed what they are intended for. You can still compile old code, you just won't have full access to new features if you choose to do so. This provides a way to keep legacy systems alive while providing an upgrade path for them at the same time.
  - 0xffff2 6y ago
    >>If a programming language evolves to the point that previous programs written in that language no longer compile then it's no longer the same language. >I don't really buy that you cannot ever introduce breaking changes. That's a recipe for disaster and IMHO short-sighted. It's also empirically true in my experience. See Python2/Python3, Perl/Raku, C++98/C++11/C++20. In the latter case, I'm not even sure there are any significant breaking changes, but the feature sets are so different that I find that I pretty much always have to specify which version of C++ I'm talking about.
  - guenthert 6y ago
    Well, C hasn't been designed to be evolving and was also quite under-specified through most of its history; a hacker's delight, a tool to get things done, quick, but not a receipt for long-term maintainability. Given that, I'd think C did rather well.
- noelwelsh 6y ago
  Scala has a tool called scalafix (https://scalacenter.github.io/scalafix/ https://scalacenter.github.io/scalafix/) which allows people to write migration scripts (and other things) that work based on analysis of existing code. This has been used for library upgrades, and will play a big part in the Scala 2 -> Scala 3 migration coming at the end of the year. So it's not impossible to evolve a language and keep code bases current with minimal work for the end user. For such a tool to be effective it must be possible to statically analyse code to a reasonable degree, and C is certainly not a language that enables easy static analysis.
- Gibbon1 6y ago
  On the other hand it's absolutely pathetic that C still doesn't have actual arrays. To head off comments, no syntactic sugar on top of pointers doesn't count at all. So don't even try to make that argument.
Oote3eep 6y ago
Well, precisely : if people want modern/innovating/fast evolving languages, they can use Rust, Go, Elixir, etc. I actually started using C for my side projects since two years precisely because I want very long term backward compatibility (that is, being able to leave a program for years without maintaining it, then make a small edit in it and build it with minimum pain). C is perfect for that, and I agree with the sentiment that backward compatibility is its most important feature.
- deleted 6y ago
  [deleted]
- coder543 6y ago
  > I actually started using C for my side projects since two years precisely because I want very long term backward compatibility (that is, being able to leave a program for years without maintaining it, then make a small edit in it and build it with minimum pain). Rust actually takes a very strong stance on maintaining backwards compatibility, and Go's stance is arguably even stronger in most cases. You're implying incorrectly that these languages are just breaking things left and right for no reason other than "innovation!", which isn't true. The overwhelming majority of Rust and Go code from years ago will compile without problems today. Any code from post-1.0 that doesn't compile today was (inadvertently) relying on buggy, incorrect behaviors that have since been fixed... and even then, not all incorrect behaviors get fixed because compatibility is considered so important. C is fine for certain applications, but no one should choose it for side projects based on some notion of backwards compatibility, in my opinion. If some company is building a business application that needs "backwards compatibility" in the sense that it can run on all sorts of arcane microarchitectures and operating systems, then sure... C is still a really painful* choice, but it might be the right choice then, or if there's an existing C code base, then it probably doesn't make business sense to rewrite it any time soon. * yes, having no protection from footguns, no real standard library, no built-in concept of asynchronous code, and very little of anything useful is definitely painful. If C is the only valid choice for a project, then it's the only valid choice, and that's what you have to do. The number of projects where you simply can't use something other than C is diminishing by the day.
ksec 6y ago
>(cough Rust cough) Or Zig? What other potential C replacement are there?
- mhh__ 6y ago
  D's betterC mode is very good. It's slightly above C in abstraction (i.e you still have generics) but you get all the metaprogramming too (no more macros!)
  - virtue3 6y ago
    Nothing like a good ole: #define MULTIPLY(a,b) a*b To ruin your month.
    - blovescoffee 6y ago
      Is the problem the use of a macro, which isn't as robust as a template, or is there a problem with the macro? All I can figure is there could be an accidental dereference instead of multiply.
      - virtue3 6y ago
        The problem is macro expansion is not (potentially) what you think it is: MULTIPLY(2+3,4+5) that expands in 2+34+5 (and not into: (2+3)(4+5)). To have the latter, you should define: #define MULTIPLY(a,b) ((a)*(b)) https://stackoverflow.com/questions/14041453/why-are-preprocessor-macros-evil-and-what-are-the-alternatives#:~:text=The%20trouble%20with%20macros%20is,comes%20down%20to%20personal%20preference https://stackoverflow.com/questions/14041453/why-are-preproc....
        favorited 6y ago
        But it's so nice and composable! /s #define DEREFERENCE(b) MULTIPLY(=, b) int thing DEREFERENCE(ptr);
        6y ago
CodeArtisan 6y ago
I pray daily that more of my fellow programmers may find the means of freeing themselves from the curse of compatibility. -- Edsger Dijkstra - 1972, Turing award lecture
- quickthrower2 6y ago
  The “trade off” not “curse” imho. But what’s the point he is making. Is there a link to that lecture?
flingo 6y ago
> And this is how backwards compatibility comes to kill innovation. With all of the novel and esoteric programming languages that exist, I wonder why hasn't there been a "I can't believe it's not c/c++" language that breaks these things, but isn't taken seriously enough to diverge completely from the ISO language standards. (for bonus points, with standardized gcc extensions, and something like embedded asm but for compiled languages (like iso standard c))

schemy 6y ago

Rust is the future and always will be.

deleted 6y ago
[deleted]

mytailorisrich 6y ago

IMHO that's how it should be for a programming language. If a programming language evolves to the point that previous programs written in that language no longer compile then it's no longer the same language. So let's keep C as C and, as you point out, new ideas and concepts that would break things can be implemented in new languages. C does evolve but it's also taken the pragmatic approach not to break the huge existing code base it has. In many cases these programs have been running for decades, they work.

Tehnix 6y ago
>If a programming language evolves to the point that previous programs written in that language no longer compile then it's no longer the same language. I don't really buy that you cannot ever introduce breaking changes. That's a recipe for disaster and IMHO short-sighted. >In many cases these programs have been running for decades, they work. And in many other cases, they have been full of security holes that take an incredible amount of work to discover. Something like Rust's editions seems to solve this problem very well, and is indeed what they are intended for. You can still compile old code, you just won't have full access to new features if you choose to do so. This provides a way to keep legacy systems alive while providing an upgrade path for them at the same time.
- 0xffff2 6y ago
  >>If a programming language evolves to the point that previous programs written in that language no longer compile then it's no longer the same language. >I don't really buy that you cannot ever introduce breaking changes. That's a recipe for disaster and IMHO short-sighted. It's also empirically true in my experience. See Python2/Python3, Perl/Raku, C++98/C++11/C++20. In the latter case, I'm not even sure there are any significant breaking changes, but the feature sets are so different that I find that I pretty much always have to specify which version of C++ I'm talking about.
- guenthert 6y ago
  Well, C hasn't been designed to be evolving and was also quite under-specified through most of its history; a hacker's delight, a tool to get things done, quick, but not a receipt for long-term maintainability. Given that, I'd think C did rather well.
noelwelsh 6y ago
Scala has a tool called scalafix (https://scalacenter.github.io/scalafix/ https://scalacenter.github.io/scalafix/) which allows people to write migration scripts (and other things) that work based on analysis of existing code. This has been used for library upgrades, and will play a big part in the Scala 2 -> Scala 3 migration coming at the end of the year. So it's not impossible to evolve a language and keep code bases current with minimal work for the end user. For such a tool to be effective it must be possible to statically analyse code to a reasonable degree, and C is certainly not a language that enables easy static analysis.
Gibbon1 6y ago
On the other hand it's absolutely pathetic that C still doesn't have actual arrays. To head off comments, no syntactic sugar on top of pointers doesn't count at all. So don't even try to make that argument.

Oote3eep 6y ago

Well, precisely : if people want modern/innovating/fast evolving languages, they can use Rust, Go, Elixir, etc. I actually started using C for my side projects since two years precisely because I want very long term backward compatibility (that is, being able to leave a program for years without maintaining it, then make a small edit in it and build it with minimum pain). C is perfect for that, and I agree with the sentiment that backward compatibility is its most important feature.

deleted 6y ago
[deleted]
coder543 6y ago
> I actually started using C for my side projects since two years precisely because I want very long term backward compatibility (that is, being able to leave a program for years without maintaining it, then make a small edit in it and build it with minimum pain). Rust actually takes a very strong stance on maintaining backwards compatibility, and Go's stance is arguably even stronger in most cases. You're implying incorrectly that these languages are just breaking things left and right for no reason other than "innovation!", which isn't true. The overwhelming majority of Rust and Go code from years ago will compile without problems today. Any code from post-1.0 that doesn't compile today was (inadvertently) relying on buggy, incorrect behaviors that have since been fixed... and even then, not all incorrect behaviors get fixed because compatibility is considered so important. C is fine for certain applications, but no one should choose it for side projects based on some notion of backwards compatibility, in my opinion. If some company is building a business application that needs "backwards compatibility" in the sense that it can run on all sorts of arcane microarchitectures and operating systems, then sure... C is still a really painful* choice, but it might be the right choice then, or if there's an existing C code base, then it probably doesn't make business sense to rewrite it any time soon. * yes, having no protection from footguns, no real standard library, no built-in concept of asynchronous code, and very little of anything useful is definitely painful. If C is the only valid choice for a project, then it's the only valid choice, and that's what you have to do. The number of projects where you simply can't use something other than C is diminishing by the day.

ksec 6y ago

>(cough Rust cough) Or Zig? What other potential C replacement are there?

mhh__ 6y ago
D's betterC mode is very good. It's slightly above C in abstraction (i.e you still have generics) but you get all the metaprogramming too (no more macros!)
- virtue3 6y ago
  Nothing like a good ole: #define MULTIPLY(a,b) a*b To ruin your month.
  - blovescoffee 6y ago
    Is the problem the use of a macro, which isn't as robust as a template, or is there a problem with the macro? All I can figure is there could be an accidental dereference instead of multiply.
    - virtue3 6y ago
      The problem is macro expansion is not (potentially) what you think it is: MULTIPLY(2+3,4+5) that expands in 2+34+5 (and not into: (2+3)(4+5)). To have the latter, you should define: #define MULTIPLY(a,b) ((a)*(b)) https://stackoverflow.com/questions/14041453/why-are-preprocessor-macros-evil-and-what-are-the-alternatives#:~:text=The%20trouble%20with%20macros%20is,comes%20down%20to%20personal%20preference https://stackoverflow.com/questions/14041453/why-are-preproc....
      - favorited 6y ago
        But it's so nice and composable! /s #define DEREFERENCE(b) MULTIPLY(=, b) int thing DEREFERENCE(ptr);
        6y ago

CodeArtisan 6y ago

I pray daily that more of my fellow programmers may find the means of freeing themselves from the curse of compatibility. -- Edsger Dijkstra - 1972, Turing award lecture

quickthrower2 6y ago
The “trade off” not “curse” imho. But what’s the point he is making. Is there a link to that lecture?

flingo 6y ago

> And this is how backwards compatibility comes to kill innovation. With all of the novel and esoteric programming languages that exist, I wonder why hasn't there been a "I can't believe it's not c/c++" language that breaks these things, but isn't taken seriously enough to diverge completely from the ISO language standards. (for bonus points, with standardized gcc extensions, and something like embedded asm but for compiled languages (like iso standard c))