Despite its age, despite many flaws, C is still the de facto standard, the lingua franca. Why? As with other older languages, inertia is partly to blame, but this cannot be the only reason. C must possess a near-perfect balance of vital language features.
A flawed premise. Why must C contain a new-perfect balance of vital language features to persist? Why can inertia and familiarity not be to blame?
It's fine to list C's qualities, it has many (and it also has many warts), but if your opening statement makes two very powerful and clear assertions such as those, you would think they would be the point of the article, or at a minimum addressed within the body. They are not.
There are multiple things on both sides here. The author more or less asserted without evidence that inertia isn't the dominant term.
Also, inertia might not be a good analogy. Things with inertia might move slowly but will move eventually even given the smallest force. This is probably more like energy wells where you can become trapped in a local minimum.
I started off with C 15 years ago, but now I find myself migrated, by and large, to C++. Everything that's good about C exists in C++, and all of the missing components (string support, smart pointers, tuples, maps, STL data structures) make life much easier. On top of that, it's the exact same compiler for both C and C++ on most platforms.
Thankfully everything that's bad about C++ is absent in C. My least favorite term in CS is "C/C++" because they are two totally different languages, suitable for for totally different problems, and C++ is a smear on C's otherwise good name.
You're probably better off using Go then. If you like C++ but wish it were better you want Rust, and if you like C but wish it were better you want Go.
In Go I can't `extern C` and calling C functions is expensive. I will probably be using Rust for some projects in the future, but right now I'm reliant on C++ for stuff like Eigen (numerical linear algebra) and OpenMP (shared memory loop parallelism).
Strange, I though that C++ has to thank C for implicit conversions, unsafe enums, memory corruption due to out-of-bounds in string and memory handling functions, UB, slow compilation times due to text inclusion, lack of code understanding due to macros über all, weak linking, ...
For me it's exactly the other way around. Spent 20 years in C++ (before that 5 years of C), but slowly and steady got fed up by the language complexity, redundant features, standard library bloat and compiles times. Went back to C and it's like a breath of fresh air.
The turning point for me was realizing that C++ mostly helps with managing the complexity of many small memory allocations, but it's better to avoid such a "many small memory allocations" scenario to begin with. And without that, C++ looses much of its appeal over C.
If you're not using the type safety and error handling afforded by C++ you're probably not using C++11. (reminder: latest version is C++17 which brings much higher usability at compiler implementation complexity cost)
Where C++ in modern form helps is generally getting rid of unsafe accesses and uses.
I'll take exceptions over checking error codes all the time.
Don't you miss virtual functions? I found that no matter how you did it, implementing polymorphism in C (with function pointers) is tedious and verbose ; also, it discourages the creation of new interfaces (too much boilerplate).
Started in C 35 years ago, migrated to C++ for about 10 or 15, and now try and avoid C++ but am perfectly amenable to a little C if the situation suits.
The extreme ugliness and overhead of C++ was wearing, as was the occasional zealotry of those who knew C++ but never went through a just C phase.
These days I've seen enough different languages to mostly not care that much.
I've had just a cursory read through the C++ vs C version. Constructors can never fail? Nope, exceptions. If you think constructors should never fail, I think you haven't used malloc.
Templates are complex? Compared to preprocessor they're child's play. They're meant to replace most uses of preprocessor.
Other compile time code like constexpr is not mentioned.
Exceptions are not mentioned yet are actually the most complex C++ machinery.
Scope changes are not mentioned but are critical to RAII and other useful anti-bug features.
That you can actually enforce compile time type safety is not mentioned either.
Lambasting the extra visibility keywords when C already has the nastiness of static, extern and inline is very peculiar. They are also essentially type safety measures.
C++ standard library which is strictly superior to C is not mentioned either.
C++ may not be perfect but at least it is being improved. C is the unchanged ancient form where the main gain is that it does not have stack frame unwinding and has trivial ABI.
Sure, C is great in its simplicity but the world has moved on to safer more powerful languages. Yes, I am referring to Rust, and yes, while it can be awkward and annoying sometimes with it's ownership lifetimes, as a professional it gives me great confidence to know that the next crash in the system will not be because of my code.
I think the terminal includes a lot of GNU utilities, so that's likely true. That doesn't actually conflict with anything I said though. I'm sure the GUI code is quite large, given that the system is meant to be maintained and usable from entirely within that context.
OS X is basically the XNU kernel (written mostly in C) + the FreeBSD userland (written mostly in C) + a few GNU utilities (written mostly in C) + a bunch of Apple stuff like iTunes, Safari, etc. (Written mostly in C++ and Objective-C). It's not really a "fork" of FreeBSD.
> Sure, C is great in its simplicity but the world has moved on to safer more powerful languages.
Sure, we have more type safe languages. But I wouldn't call one language "more powerful" than another. Certainly Rust isn't "more powerful" than C. They are both turing complete and equally "powerful".
There's way too much love for C when it has some huge flaws. I can agree on simplicity, portability, speed. But having archaic String and file handling are huge frustrations. Function pointers are nice, but modern languages already have functional programming constructs that supersede it. Goto's should be avoided for good reason. As for brevity? How about just having good naming in your variables. Something that isn't HammerHammerHammerFactory but something that doesn't require a user to sift through the entire code to guess what an important variable does because it's a three character variable.
> Q: What do you think of the projects currently underway to develop OS kernels in languages like Rust (touted for having built-in safeties that C does not)?
>
> A: That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters.
>
> I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations.
This article is frustrating to me. So many modern languages and toolsets are omitted from the comparisons provided that the conclusions, to me, lack authority. But they're presented as if they're obvious, almost trivial.
I have great respect for C. But it's only one language and it solves one set of problems. I'm not even sure the concept of a "desert island language" is valid - except to ask "what tool would you want to have to build the tools you actually want?"
In that case, the answer might be C, but the article doesn't do any kind of job showing that.
Pretty sure that Forth is the desert island language if that means that we are starting from machine code. If we get to pick an entire language ecosystem then I choose the one with the best boat building libraries.
49 comments
[ 3.3 ms ] story [ 116 ms ] threadA flawed premise. Why must C contain a new-perfect balance of vital language features to persist? Why can inertia and familiarity not be to blame?
It's fine to list C's qualities, it has many (and it also has many warts), but if your opening statement makes two very powerful and clear assertions such as those, you would think they would be the point of the article, or at a minimum addressed within the body. They are not.
positives(C) - negatives(C) + inertia(C) > positives(other) - negatives(other)
There are multiple things on both sides here. The author more or less asserted without evidence that inertia isn't the dominant term.
Also, inertia might not be a good analogy. Things with inertia might move slowly but will move eventually even given the smallest force. This is probably more like energy wells where you can become trapped in a local minimum.
> I can roughly envision the assembly generated by a C statement, so I can make educated guesses about time and space efficiency.
Ha, that sure went out the window in more recent years.
And everything else listed is pretty minor.
The turning point for me was realizing that C++ mostly helps with managing the complexity of many small memory allocations, but it's better to avoid such a "many small memory allocations" scenario to begin with. And without that, C++ looses much of its appeal over C.
Where C++ in modern form helps is generally getting rid of unsafe accesses and uses.
I'll take exceptions over checking error codes all the time.
The extreme ugliness and overhead of C++ was wearing, as was the occasional zealotry of those who knew C++ but never went through a just C phase.
These days I've seen enough different languages to mostly not care that much.
Templates are complex? Compared to preprocessor they're child's play. They're meant to replace most uses of preprocessor. Other compile time code like constexpr is not mentioned.
Exceptions are not mentioned yet are actually the most complex C++ machinery.
Scope changes are not mentioned but are critical to RAII and other useful anti-bug features.
That you can actually enforce compile time type safety is not mentioned either.
Lambasting the extra visibility keywords when C already has the nastiness of static, extern and inline is very peculiar. They are also essentially type safety measures.
C++ standard library which is strictly superior to C is not mentioned either.
C++ may not be perfect but at least it is being improved. C is the unchanged ancient form where the main gain is that it does not have stack frame unwinding and has trivial ABI.
git clone --depth=1 https://github.com/gcc-mirror/gcc.git
cloc gcc/gcc
…Yes, really. They didn't change the filenames during the migration.
No it hasn't and i am not so sure, it ever will. Good to hear that you have moved onto Rust, but that anecdata doesn't mean the world has moved on.
While the Windows kernel is supposed to be written in C, my understanding is that the majority/almost all of the rest of the system is written in C++.
Also, I think a good portion of OS X is/was written in Objective C, which some newer portion being written in Swift.
Sure, we have more type safe languages. But I wouldn't call one language "more powerful" than another. Certainly Rust isn't "more powerful" than C. They are both turing complete and equally "powerful".
And there's go. And there's D. And there's Nim.
And there's modern C++. It has improved during the last decade, and keeps improving.
It is still an open race with no clear winner.
I think the world actually moved from C/C++ to Java 15 years ago. Then a segment of developers realized it still needed C++ and went back to it.
C++ development feels more popular now than it was 10 years ago. And the language is certainly better than it was.
Slow and 'productive' languages like Python and Ruby fill another niche and are not in direct competition.
Only now with the popularity of Rust and go, there's something that C++ developers can move to, but somehow there's no clear answer.
I personally prefer D instead of Rust. And I prefer C++ to Java.
Oh Silicon Valley, you are not the world.
There's are definitely more, better options than ever though.
It's like saying that assembler is flawed. It's not; it's just may not be the right tool for the job.
I'd be very interested in his opinion of Rust
> Q: What do you think of the projects currently underway to develop OS kernels in languages like Rust (touted for having built-in safeties that C does not)? > > A: That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters. > > I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations.
Rly? Tht how u tlk?
I have great respect for C. But it's only one language and it solves one set of problems. I'm not even sure the concept of a "desert island language" is valid - except to ask "what tool would you want to have to build the tools you actually want?"
In that case, the answer might be C, but the article doesn't do any kind of job showing that.