4 ms·

I respectfully disagree. I think C is a giant disaster that will continue to plague us entirely due to inertia. You're really underestimating how entrenched it

I respectfully disagree. I think C is a giant disaster that will continue to plague us entirely due to inertia. You're really underestimating how entrenched it is. Try to go program on micro in something other than C. Try programming a driver. The toolchains simply don't exist - the comparability with several decades of work is also shaky. C is a terrible cross platform assembly b/c it doesn't allow you the level of control which one would expect in this day and age. Maybe it was written in the days when CPUs were brain-dead simple, but basic things that are available on most architectures aren't part of the language. It has no notion of a CPU cache, it has no notion of branching (you can't tag a likely branch and an unlikely one), it even goes as far as to ignore user keywords for inlining and provides no keyword for blocking inlining. RVO is implicit magic that you just pray happens. Const != immutability. When you write C you have no notion of what the compiler is going to output whatsoever A lot of these things are available through compiler extensions (so great, now it's not cross-platform), but even still the language is broken. "Expert C Programming" has a really long chapter that goes over all the more confusing subtly problems C has beyond just arrays being pointers-but-not-really. I have to use C pretty regularly and all I can think is "God.. why hasn't anyone made this better yet"

clifanatic 10y ago
> When you write C you have no notion of what the compiler is going to output whatsoever Well, sort of... but what language isn't that true of? And really, what language isn't that more true of than C?
- hga 10y ago
  Higher level ones who's compilers can better reason about the code? See for example more generally Fran Allen's comments in Coders At Work for how desolate a optimization wasteland is C.
  - AnimalMuppet 10y ago
    I think you're looking at this backwards from clifanatic's point. The more a higher-level compiler can reason about the code, the more optimizations it can perform, the less the compiler output resembles the source code input I gave it.
stcredzero 10y ago
It has no notion of a CPU cache, it has no notion of branching (you can't tag a likely branch and an unlikely one), it even goes as far as to ignore user keywords for inlining and provides no keyword for blocking inlining. RVO is implicit magic that you just pray happens. Const != immutability. What language has all of these covered? (Rust?)
- ThatGeoGuy 10y ago
  > branching None that I know of from the last 20 years or so. > inlining This one is tricky. Sure, GCC ignoring the inline keyword is annoying, but sometimes figuring out if something is inline-able is undecidable, and sometimes things just aren't capable of being inlined. > blocking inlining This is something that I don't understand why we don't have. Sure, lots of times you would rather inline than not, but sometimes inlining the wrong expression can subtly change the performance / lookup / dispatch semantics in weird ways. I've no hard examples of this, but it should be easy enough for almost every language to have a --no-inline flag. > RVO C++11 and up somewhat handle this with move semantics. Having a separation of rvalues / lvalues certainly helps, but the distinction could probably be clearer, as it can get to be a gruesome and hairy topic depending on your types. > const != immutability That you can often just "cast the const away" is really the problem here. I think Rust improves on this space as there is no safe cast to remove const-ness, but if you ever find yourself or somebody else casting away const, you / they should realize that they are going against the design of the system. I'm still undecided if "mutable" keyword in C++ classes is so horrible in this context, as it certainly helps in making const-types usable with the rest of the language (which is inherently non-const).
  - AnimalMuppet 10y ago
    Well, in C++, "const" isn't actually intended to mean "literally const", it's supposed to mean "const in spirit". You can be const and still change some of the bits of an object if that change doesn't (semantically) change the object. To be able to do that, you need to be able to cast away const-ness. (No, I can't think of a reasonable example at the moment.) It would be fair to ask whether that intent was a good idea. It would also be fair to point out that many (most) times people cast away const-ness simply out of expediency, rather than using it the way it was intended.
ArkyBeagle 10y ago
'C' is quite sufficient for micros and drivers. Micros are supposed to be small. Python's catching on with the kids for systems programming because of Arduino. Drivers are ... well, drivers. If you write 'C', you have to look at the assembly. And adding inline assembler to manage the hardware - caching, that sort of thing - is just how it's done. Maybe it's possible to make a library ( or a bunch of #defines ) that manages this for you? I really am sorry you have to use it, but there are rather large populations of people who go completely untroubled with it.
- nickpsecurity 10y ago
  "And adding inline assembler to manage the hardware - caching, that sort of thing - is just how it's done. Maybe it's possible to make a library ( or a bunch of #defines ) that manages this for you?" The current ones might be like C on that part, might do something different. I haven't evaluated that. Here's a few: http://www.astrobe.com/Oberon.htm http://www.astrobe.com/Oberon.htm http://www.mikroe.com/mikropascal/# http://www.mikroe.com/mikropascal/# http://www.mikroe.com/mikrobasic/ http://www.mikroe.com/mikrobasic/
  - ArkyBeagle 10y ago
    Why is it we're not all using Oberon again? :) Ah, I remember having meetings about things like that... now that was inertia. SFAIK, ( meaning I don't really ) the various "Mikro" probably do the same thing that the native toolsets for , say PIC, do and simply add default, built-in symbols for bits in control registers and things like turning interrupts off/on. That keeps the amount of assembly further down. I feel confident in saying that because they'd want to make defection from the default say, AVR compiler chain as painless as possible. And of course, Linux drivers/ioctl() help a lot with bringing kernel mode things into user space. Using assembler in a driver is just one of those things we find acceptance with.
- optforfon 10y ago
  right, but once you start writing inline assembly it's no longer a "cross platform assembly" - and I think there is a demand for that. For instance the Linux kernel supports a mind-boggling amount of different architectures and "just write in-line assembly" probably doesn't cut it "large populations of people who go completely untroubled with it." Stockholm syndrome.... Or a lack of imagination about how things could be better. There really is a cult-like adoration of C - I think mostly by people that don't use it and learning it in college and long for something as simple

clifanatic 10y ago

> When you write C you have no notion of what the compiler is going to output whatsoever Well, sort of... but what language isn't that true of? And really, what language isn't that more true of than C?

hga 10y ago
Higher level ones who's compilers can better reason about the code? See for example more generally Fran Allen's comments in Coders At Work for how desolate a optimization wasteland is C.
- AnimalMuppet 10y ago
  I think you're looking at this backwards from clifanatic's point. The more a higher-level compiler can reason about the code, the more optimizations it can perform, the less the compiler output resembles the source code input I gave it.

stcredzero 10y ago

It has no notion of a CPU cache, it has no notion of branching (you can't tag a likely branch and an unlikely one), it even goes as far as to ignore user keywords for inlining and provides no keyword for blocking inlining. RVO is implicit magic that you just pray happens. Const != immutability. What language has all of these covered? (Rust?)

ThatGeoGuy 10y ago
> branching None that I know of from the last 20 years or so. > inlining This one is tricky. Sure, GCC ignoring the inline keyword is annoying, but sometimes figuring out if something is inline-able is undecidable, and sometimes things just aren't capable of being inlined. > blocking inlining This is something that I don't understand why we don't have. Sure, lots of times you would rather inline than not, but sometimes inlining the wrong expression can subtly change the performance / lookup / dispatch semantics in weird ways. I've no hard examples of this, but it should be easy enough for almost every language to have a --no-inline flag. > RVO C++11 and up somewhat handle this with move semantics. Having a separation of rvalues / lvalues certainly helps, but the distinction could probably be clearer, as it can get to be a gruesome and hairy topic depending on your types. > const != immutability That you can often just "cast the const away" is really the problem here. I think Rust improves on this space as there is no safe cast to remove const-ness, but if you ever find yourself or somebody else casting away const, you / they should realize that they are going against the design of the system. I'm still undecided if "mutable" keyword in C++ classes is so horrible in this context, as it certainly helps in making const-types usable with the rest of the language (which is inherently non-const).
- AnimalMuppet 10y ago
  Well, in C++, "const" isn't actually intended to mean "literally const", it's supposed to mean "const in spirit". You can be const and still change some of the bits of an object if that change doesn't (semantically) change the object. To be able to do that, you need to be able to cast away const-ness. (No, I can't think of a reasonable example at the moment.) It would be fair to ask whether that intent was a good idea. It would also be fair to point out that many (most) times people cast away const-ness simply out of expediency, rather than using it the way it was intended.

ArkyBeagle 10y ago

'C' is quite sufficient for micros and drivers. Micros are supposed to be small. Python's catching on with the kids for systems programming because of Arduino. Drivers are ... well, drivers. If you write 'C', you have to look at the assembly. And adding inline assembler to manage the hardware - caching, that sort of thing - is just how it's done. Maybe it's possible to make a library ( or a bunch of #defines ) that manages this for you? I really am sorry you have to use it, but there are rather large populations of people who go completely untroubled with it.

nickpsecurity 10y ago
"And adding inline assembler to manage the hardware - caching, that sort of thing - is just how it's done. Maybe it's possible to make a library ( or a bunch of #defines ) that manages this for you?" The current ones might be like C on that part, might do something different. I haven't evaluated that. Here's a few: http://www.astrobe.com/Oberon.htm http://www.astrobe.com/Oberon.htm http://www.mikroe.com/mikropascal/# http://www.mikroe.com/mikropascal/# http://www.mikroe.com/mikrobasic/ http://www.mikroe.com/mikrobasic/
- ArkyBeagle 10y ago
  Why is it we're not all using Oberon again? :) Ah, I remember having meetings about things like that... now that was inertia. SFAIK, ( meaning I don't really ) the various "Mikro" probably do the same thing that the native toolsets for , say PIC, do and simply add default, built-in symbols for bits in control registers and things like turning interrupts off/on. That keeps the amount of assembly further down. I feel confident in saying that because they'd want to make defection from the default say, AVR compiler chain as painless as possible. And of course, Linux drivers/ioctl() help a lot with bringing kernel mode things into user space. Using assembler in a driver is just one of those things we find acceptance with.
optforfon 10y ago
right, but once you start writing inline assembly it's no longer a "cross platform assembly" - and I think there is a demand for that. For instance the Linux kernel supports a mind-boggling amount of different architectures and "just write in-line assembly" probably doesn't cut it "large populations of people who go completely untroubled with it." Stockholm syndrome.... Or a lack of imagination about how things could be better. There really is a cult-like adoration of C - I think mostly by people that don't use it and learning it in college and long for something as simple