C is the desert island language
www-cs-students.stanford.edu
www-cs-students.stanford.edu
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.
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.
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.
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.
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 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.
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.
> 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.
Rly? Tht how u tlk?