5 ms·

The best things always have detractors, yet they live on. C is over 40 years old and is still in widespread use today, even though there have been (supposedly)

by CrLf 10y ago

The best things always have detractors, yet they live on. C is over 40 years old and is still in widespread use today, even though there have been (supposedly) better languages targeting the same use cases for decades now. There is more to it than just inertia. I've been using it less and less over the years, mostly because I've also been tackling less and less problems in the domains where it excels. It is still my favorite language though.

gautamdivgi 10y ago
Definitely agree there. I've moved through several languages - c, c++, java and now python. Over the years my work has progressed from real hard development to more of an analysis & design & architecture role. So, when I decided to get back in touch with programming and complete problems on online judges as a hobby - I just went with c/c++ (c++ just to use the template library).
optforfon 10y ago
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).
nickpsecurity 10y ago
"C is over 40 years old and is still in widespread use today, even though there have been (supposedly) better languages targeting the same use cases for decades now. There is more to it than just inertia." A false argument that's easy to counter with itself: COBOL is over 50 years old and still in widespread use by businesses, even though there have (supposedly) been better languages targeting the same use cases for decades now. There is more to it than just inertia. Nope, it's just inertia. Specifically, the risk of breaking stuff by rewriting it to work better, preservation of backward compatibility as a business benefit, prior investments in tooling, what people are already using vs what's new, and laziness far as hobbyists that started with it. Same reasons C and UNIX problems didn't get fixed. Sociology and economics trump technical points in adoption or continuation of languages, platforms, etc. The meme for this, per Gabriel, is "Worse is Better."
- AnimalMuppet 10y ago
  First: No, that's not the point of "worse is better". The point is that usability comes from rapidly iterating as you run into real problems, not from an ivory-tower design. The first paragraph of Gabriel's essay says: "The concept known as 'worse is better' holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Christopher Alexander might call this "piecemeal growth." This is the story of the evolution of that concept." This has nothing to do with inertia and old code bases preserving old things. Second: I would suspect that there are far more new projects started today in C than there are in COBOL. C is in use (at least sometimes) as a voluntary choice, and COBOL is not.
  - nickpsecurity 10y ago
    "First: No, that's not the point of "worse is better". " I hear lots of interpretations of it. I could be misremembering. I'll take another look at it. Appreciate the specific points to look into. :) "Second: I would suspect that there are far more new projects started today in C than there are in COBOL. C is in use (at least sometimes) as a voluntary choice, and COBOL is not." If we're using that constraint, then Java and PHP are the example with Java for about any kind of app. A lot of people even like Java. They think it's great and hate C. So on and so forth. Yet, the popularity still tells me nothing as I got to watch Java get forced by Sun and others into its position step-by-step with insane amounts of work to get it to match performance and productivity of better-designed languages... partly successful there. It was actually experience of Java IIRC (later C#) that was the reason many people didn't think an OS could be done in a GC'd language. They mentally associated GC'd language with stuff like that. That a small team pulled it off in Oberon with a handful of people at a time porting or extending it is always news to Java developers I meet here. Lack of context, bad design, meant to replace prior languages for most applications, platform orientation, and massive ecosystem + uptake + tooling make it a better comparison. So, I'll use it and COBOL next time.

by CrLf 10y ago

gautamdivgi 10y ago

Definitely agree there. I've moved through several languages - c, c++, java and now python. Over the years my work has progressed from real hard development to more of an analysis & design & architecture role. So, when I decided to get back in touch with programming and complete problems on online judges as a hobby - I just went with c/c++ (c++ just to use the template library).

optforfon 10y ago

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).

nickpsecurity 10y ago

"C is over 40 years old and is still in widespread use today, even though there have been (supposedly) better languages targeting the same use cases for decades now. There is more to it than just inertia." A false argument that's easy to counter with itself: COBOL is over 50 years old and still in widespread use by businesses, even though there have (supposedly) been better languages targeting the same use cases for decades now. There is more to it than just inertia. Nope, it's just inertia. Specifically, the risk of breaking stuff by rewriting it to work better, preservation of backward compatibility as a business benefit, prior investments in tooling, what people are already using vs what's new, and laziness far as hobbyists that started with it. Same reasons C and UNIX problems didn't get fixed. Sociology and economics trump technical points in adoption or continuation of languages, platforms, etc. The meme for this, per Gabriel, is "Worse is Better."

AnimalMuppet 10y ago
First: No, that's not the point of "worse is better". The point is that usability comes from rapidly iterating as you run into real problems, not from an ivory-tower design. The first paragraph of Gabriel's essay says: "The concept known as 'worse is better' holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Christopher Alexander might call this "piecemeal growth." This is the story of the evolution of that concept." This has nothing to do with inertia and old code bases preserving old things. Second: I would suspect that there are far more new projects started today in C than there are in COBOL. C is in use (at least sometimes) as a voluntary choice, and COBOL is not.
- nickpsecurity 10y ago
  "First: No, that's not the point of "worse is better". " I hear lots of interpretations of it. I could be misremembering. I'll take another look at it. Appreciate the specific points to look into. :) "Second: I would suspect that there are far more new projects started today in C than there are in COBOL. C is in use (at least sometimes) as a voluntary choice, and COBOL is not." If we're using that constraint, then Java and PHP are the example with Java for about any kind of app. A lot of people even like Java. They think it's great and hate C. So on and so forth. Yet, the popularity still tells me nothing as I got to watch Java get forced by Sun and others into its position step-by-step with insane amounts of work to get it to match performance and productivity of better-designed languages... partly successful there. It was actually experience of Java IIRC (later C#) that was the reason many people didn't think an OS could be done in a GC'd language. They mentally associated GC'd language with stuff like that. That a small team pulled it off in Oberon with a handful of people at a time porting or extending it is always news to Java developers I meet here. Lack of context, bad design, meant to replace prior languages for most applications, platform orientation, and massive ecosystem + uptake + tooling make it a better comparison. So, I'll use it and COBOL next time.