4 ms·

I agree with everything you raise here. C is a dinosaur that should be left to museums. But I’m really, really tired of people comparing c interchangeably with

by e-dant 5y ago

I agree with everything you raise here. C is a dinosaur that should be left to museums. But I’m really, really tired of people comparing c interchangeably with c++ — and, more than anything else, if you have a good idea please just make a pull request on someone’s git repo. And just in case anyone is unclear about this, if you ship code with unbounded memory leaks you’re going to hell

sirwhinesalot 5y ago
More than anything C should have had "slices" (aka fat pointers) added to the language. They wouldn't solve issues like use after free but they would enable sane ways of working with strings and buffers like every other language in existence. Instead we got VLAs (now deprecated) and _Generic. Neat but who cares? The C standards committee doesn't really know what to do with the language it seems.
- e-dant 5y ago
  The purpose of C was to be an optimizable low-level language. If programmers wanted those things, the sense was always one of “ok, do it yourself and use it as a library.” There are definite pros and cons to that particular standards methodology. It is, without any question, the most distributable language. The ABI is and will likely always be intact. Nobody has ever argued that C is anything other than that. It’s about as dead simple as it can be. There are other languages for other purposes. Rust and C++ are, in all cases I’m aware of, equivalent in performance to their “ideal” C program alternatives. Nobody has ever argued until just recently that C is or ever has been anything other than what it is or that there is some kind of battle going on between Rust and “c/c++.” Nothing could be more untrue. C and C++ are different things. Though, with a clear lack of understanding you can write a “c” program in c++. The same is true with rust — everything can still be mutable and you can still have undefined behavior very easily (perhaps most easily with IO). Plenty of other languages exist, too, with other ways of solving these problems. Haskell is a wonderful language which I hope someday to develop with if there was only some way of making it easier to work with file systems without a PHD. This particular flame war between rust, c, and c++ is so contrived and tired and misleading.
  - sirwhinesalot 5y ago
    Eh that's rather revisionist, C was a high-level language for the 70s. It isn't nowadays because there are languages that are so much higher level that it is low level in comparison. It's not much different from Fortran in that regard. Rather than the purpose of C being an optimizable low-level language, it's more accurate to say that is the niche it carved out for itself. There's plenty of crap in C that doesn't help with either optimization or a good ABI.
    - fivea 5y ago
      > Eh that's rather revisionist, C was a high-level language for the 70s. No, not really. C was always, right from the start, a kin to portable assembly. You'd be hard pressed to come up with a language from the 70s which was at the same level or lower than C. Neigher Fortran nor COBOL nor ALGOL nor Lisp nor BASIC were lower level than C. Precisely which language, other than assembly, leads you to believe that C ever was considered a high-level language? I don't understand what leads anyone to argue otherwise.
      - sirwhinesalot 5y ago
        All languages back then, all of them, were "high-level" languages, including C. Look at the history of BCPL, B and C and how the goal was to write Unix in a "high-level" language. You can go hear Brian Kernighan himself tell you all about it. C as a low-level language is revisionist history. Rust is a high-level language and yet it is a "lower level" language than Java. Same as C vs Pascal. You could write very low level code in Turbo Pascal back in the 80s, the demoscene used it a lot alongside assembly, it had inline assembly even. EDIT: and to answer your question on what else was "low-level", Forth.
        fivea 5y ago
        > All languages back then, all of them, were "high-level" languages, including C. The only interpretation where this assertion rings remotely true is if you follow a definition of "high level language" which boils down to "it's not assembly", which has not been the case for around half a century. It makes absolutely no sense to claim that languages such as COBOl and C are even close at the same level of abstraction, just because C is compiled, has loops, and has a standard library.
- fivea 5y ago
  > The C standards committee doesn't really know what to do with the language it seems. Honest question: why should C change? I mean, if all we want is access to higher-level core language features not provided by C, isn't it better to just pick up a higher-level language that already offers it? After all, if you add higher level features like smart pointers, is it really worth it to keep other features like the extensive reliance on the C preprocessor, dangerous string handling, and a spartan and in some cases outright unsafe standard library? Or would it be better to cut our losses and just adopt languages that already fixed those issues?
  - e-dant 5y ago
    Honest answer: of course it is, and no serious developer is arguing otherwise. I just finished shipping an industrial lighting unit for “smart farms.” I worked extensively on embedded hardware. The most advanced processor I used was armv6, with the majority of hardware being IC or FPGA. I used C for one thing only: reading the bitstream from microcontrollers into memory. After which point, I used c++ (17) with exclusively standard libraries (one exception: boost’s ASIO for http) to implement any and all other features. I would have happily used c++ to read those bitstreams, but the code was so unsafe that it refused to compile. Turns out that reading raw bytes from an irregular file descriptor is so arcane and bizarre that no sane modern compiler felt good enough about itself to allow me to compile it. All that said, I would only ever allow myself to write in C in that isolated case and for that isolated purpose. Every other nanosecond of my codebase runs on modern c++. Honest answer, there is no legitimate reason to use C. If in some edge case you must, there is no legitimate reason to use it for anything other than that.
  - sirwhinesalot 5y ago
    But is is changing, the standards committee keeps adding things. Some of those are reasonable (stdbool.h, atomics), others are head scratchers (VLAs, now deprecated). It might have been better for C to have stayed frozen in time. But look how many libraries are written in C, such that they can be made available everywhere. Look at how many are written in C++/Rust but with C wrappers with plenty of pointers and bad error handling. Any improvements to the C standard would have meant a safer surface area for those languages to use to talk to other languages, since C is the english of programming. There's no reason why C couldn't have namespacing, out-of-band errors, fat pointers, minimal reflection (typeof), standardized attributes, etc. ages ago. None of that would have screwed with the ABI or with optimization, but would have made language interoperability a lot easier.
mrich 5y ago
> comparing c interchangeably with c++ For the sake of the arguments made with regards to using Rust instead, they are exactly the same and comparable - both do not have memory safety, suffer from races and lots of undefined behavior. That was the whole argument. Sure, you can use only parts of C++ and use RAII to make much of that go away. But then again you can do the same in C. And nobody can enforce that everyone adheres to it.

by e-dant 5y ago

sirwhinesalot 5y ago

More than anything C should have had "slices" (aka fat pointers) added to the language. They wouldn't solve issues like use after free but they would enable sane ways of working with strings and buffers like every other language in existence. Instead we got VLAs (now deprecated) and _Generic. Neat but who cares? The C standards committee doesn't really know what to do with the language it seems.

e-dant 5y ago
The purpose of C was to be an optimizable low-level language. If programmers wanted those things, the sense was always one of “ok, do it yourself and use it as a library.” There are definite pros and cons to that particular standards methodology. It is, without any question, the most distributable language. The ABI is and will likely always be intact. Nobody has ever argued that C is anything other than that. It’s about as dead simple as it can be. There are other languages for other purposes. Rust and C++ are, in all cases I’m aware of, equivalent in performance to their “ideal” C program alternatives. Nobody has ever argued until just recently that C is or ever has been anything other than what it is or that there is some kind of battle going on between Rust and “c/c++.” Nothing could be more untrue. C and C++ are different things. Though, with a clear lack of understanding you can write a “c” program in c++. The same is true with rust — everything can still be mutable and you can still have undefined behavior very easily (perhaps most easily with IO). Plenty of other languages exist, too, with other ways of solving these problems. Haskell is a wonderful language which I hope someday to develop with if there was only some way of making it easier to work with file systems without a PHD. This particular flame war between rust, c, and c++ is so contrived and tired and misleading.
- sirwhinesalot 5y ago
  Eh that's rather revisionist, C was a high-level language for the 70s. It isn't nowadays because there are languages that are so much higher level that it is low level in comparison. It's not much different from Fortran in that regard. Rather than the purpose of C being an optimizable low-level language, it's more accurate to say that is the niche it carved out for itself. There's plenty of crap in C that doesn't help with either optimization or a good ABI.
  - fivea 5y ago
    > Eh that's rather revisionist, C was a high-level language for the 70s. No, not really. C was always, right from the start, a kin to portable assembly. You'd be hard pressed to come up with a language from the 70s which was at the same level or lower than C. Neigher Fortran nor COBOL nor ALGOL nor Lisp nor BASIC were lower level than C. Precisely which language, other than assembly, leads you to believe that C ever was considered a high-level language? I don't understand what leads anyone to argue otherwise.
    - sirwhinesalot 5y ago
      All languages back then, all of them, were "high-level" languages, including C. Look at the history of BCPL, B and C and how the goal was to write Unix in a "high-level" language. You can go hear Brian Kernighan himself tell you all about it. C as a low-level language is revisionist history. Rust is a high-level language and yet it is a "lower level" language than Java. Same as C vs Pascal. You could write very low level code in Turbo Pascal back in the 80s, the demoscene used it a lot alongside assembly, it had inline assembly even. EDIT: and to answer your question on what else was "low-level", Forth.
      - fivea 5y ago
        > All languages back then, all of them, were "high-level" languages, including C. The only interpretation where this assertion rings remotely true is if you follow a definition of "high level language" which boils down to "it's not assembly", which has not been the case for around half a century. It makes absolutely no sense to claim that languages such as COBOl and C are even close at the same level of abstraction, just because C is compiled, has loops, and has a standard library.
fivea 5y ago
> The C standards committee doesn't really know what to do with the language it seems. Honest question: why should C change? I mean, if all we want is access to higher-level core language features not provided by C, isn't it better to just pick up a higher-level language that already offers it? After all, if you add higher level features like smart pointers, is it really worth it to keep other features like the extensive reliance on the C preprocessor, dangerous string handling, and a spartan and in some cases outright unsafe standard library? Or would it be better to cut our losses and just adopt languages that already fixed those issues?
- e-dant 5y ago
  Honest answer: of course it is, and no serious developer is arguing otherwise. I just finished shipping an industrial lighting unit for “smart farms.” I worked extensively on embedded hardware. The most advanced processor I used was armv6, with the majority of hardware being IC or FPGA. I used C for one thing only: reading the bitstream from microcontrollers into memory. After which point, I used c++ (17) with exclusively standard libraries (one exception: boost’s ASIO for http) to implement any and all other features. I would have happily used c++ to read those bitstreams, but the code was so unsafe that it refused to compile. Turns out that reading raw bytes from an irregular file descriptor is so arcane and bizarre that no sane modern compiler felt good enough about itself to allow me to compile it. All that said, I would only ever allow myself to write in C in that isolated case and for that isolated purpose. Every other nanosecond of my codebase runs on modern c++. Honest answer, there is no legitimate reason to use C. If in some edge case you must, there is no legitimate reason to use it for anything other than that.
- sirwhinesalot 5y ago
  But is is changing, the standards committee keeps adding things. Some of those are reasonable (stdbool.h, atomics), others are head scratchers (VLAs, now deprecated). It might have been better for C to have stayed frozen in time. But look how many libraries are written in C, such that they can be made available everywhere. Look at how many are written in C++/Rust but with C wrappers with plenty of pointers and bad error handling. Any improvements to the C standard would have meant a safer surface area for those languages to use to talk to other languages, since C is the english of programming. There's no reason why C couldn't have namespacing, out-of-band errors, fat pointers, minimal reflection (typeof), standardized attributes, etc. ages ago. None of that would have screwed with the ABI or with optimization, but would have made language interoperability a lot easier.

mrich 5y ago

> comparing c interchangeably with c++ For the sake of the arguments made with regards to using Rust instead, they are exactly the same and comparable - both do not have memory safety, suffer from races and lots of undefined behavior. That was the whole argument. Sure, you can use only parts of C++ and use RAII to make much of that go away. But then again you can do the same in C. And nobody can enforce that everyone adheres to it.