My collection of C-related rants
2016-09-24 22:54 by Ian
I would qualify the strong reactions I receive to "C/C++ programmer" in the Bay Area as being one of two things, "Admiration" or "Supercilious". I had to look up "Supercilious" just now to ensure that it was the best word.
It is impossible for me to conceal the fact that I know C.
My job title is "Firmware Engineer", and basically everyone in my professional circles (programmer or not) comes to the correct conclusion without me uttering a third word.
"That guy knows C."
Other engineers who see something like this on my desk will also come to the correct conclusion before I say anything.
How do they already know I speak C?
Did I use "typedef" in conversation again?
I thought I had that under control...
They come to the correct conclusion so reliably because they are following a chain of inference that has held true for more than 40 years. Apart from assembly, C/C++ is the only platform-agnostic way to deal directly with hardware and incur no dependencies.
So the thing that needs to be made clear is this: C is a permanent fixture. It is not going anywhere in your lifetime. You can use it, or not.
Regarding efforts to murder C...
I say "Rust" here because I think Rust stands the best chance of replacing C (for those of you that see C as something to replace). But please substitute for whatever "new-hotness" language you like. The questions and arguments are exactly the same.
I can't count how many times I've heard people on the internet say that Rust should replace C. Or that C is a relic, and we should all stop using it.
FWIW, the little I've used Go, I like it. But I think it lives in a very awkward niche, and on-paper, I think Haskell and Rust are both more appealing.
This is a ranty post, but what follows is not baiting. I honestly do not know the answers to these questions.
- Will Rust run on an 8-bit CPU?
- Will Rust run on 512 bytes of RAM? That is not a typo.
- Can I partition variables into specific memory segments? Remember.... Not all memory is equal.
Some segments cannot execute.
Some segments are shared with I/O.
Some segments are I/O.
Some segments cannot be used with DMA.
Some segments are zero wait-state.
Some segments are read-only, or write-only. I could go on, but I won't.
- Can I write in assembly? This is a universal requirement for hardware support of fancy new CPU features like floating-point co-processors and SIMD instruction sets.
- Can I use the linker (or the Rust equivalent) to enforce alignment boundaries when necessary?
UPDATE: One of my friends sent me a blog post by someone who has answered a few of my questions above. But I believe my argument stands. He himself says...
"I also would like to design safer APIs instead of simply translating the code to Rust."
Carefully reading the post will show you that he hasn't replaced C. He is providing a Rust runtime that sits on-top of his hardware support. To say that he has replaced C with Rust would be like saying that Java can replace C because the JNI exists.
The hard truth of Rust's viability as a C-replacement
Anyone not fully understanding the definitions of any of the bolded words in those questions does not possess enough knowledge to credibly tell me that Rust (or anything else) can replace C. Lurk mo4r.
As long as the answer to any of those questions is "No", Rust doesn't even exist as far as my world is concerned, and your Rust environment will be sitting on top of design choices made by engineers in my world for at-least the next decade.
You need to understand that all support flows from hardware. "Cloud" is an empty metaphor.
If the hardware people can't use Rust, then they won't. And for any given task that someone needs to run in firmware, they will not be using Rust libraries.
As a consequence, there is absolutely zero incentive to re-write decades of non-hardware C-libraries, (thus breaking their platform generality), for the sake of making them "safe" to use by people who don't know how computers work.
If you are advocating for Rust because of its safety features, please understand that your values do not register on my radar.
With the possible exception of Android devices, >95% of the code running on your computer (by execution time) right this moment was written in C or C++. And I can say this without knowing anything about your computer. The fact that your computer state doesn't immediately collapse into an entropic mess is hard evidence against the claim that C is unsafe.
Programmers are unsafe. C does exactly what it is meant to do. I can write safe code. Why can't you?
Despite have aesthetic opinions about C/C++, aesthetics have absolutely nothing to do with my choice to use C/C++. Point-of-fact, some of the ugliest code I've seen in 25 years of reading code has been C/C++.
I unapologetically choose C/C++ for control.
Pejorate these values if you like. Call it machismo, arrogance, stubbornness, masochism, whatever. But understand that my values in languages have taken me places on accident that most programmers couldn't travel to if they consciously tried. I'm equally-comfortable in code bases that deal with computer vision, cryptography, hardware, high-performance VoIP/video CODECs, PID-control and inertial guidance, software-defined radio.... I could go on and on.
And like it or not, you depend on someone having these values and knowledge.
It might as well be me.
C is not a low-level language
I don't care what you have read or been told. If it conflicts with the statement above, it is wrong.
The fact is: A single instruction in C is turned into many instructions by a chain of tools that you do not need to comprehend in order to write programs in C.
I've been writing C code for more than half my life. I am still learning about those tools.
It takes me about 4 hours to completely learn any given assembly language. (Except my first (68HC11), and my first 32-bit [MCF5206]). The subsequent 4 were a breeze.
This is not a boast. Assembly languages really are that simple if you understand how a computer works.
"Easy" and "simple" are orthogonal ideas.
Writing anything in assembly is a humbling experience, because you will quickly be shown just how much you take for granted, and you will never again call C "low-level".
C99's draft is not a light read. It would take me dozens of hours to READ that specification, let alone fully-comprehend it.
C is a "high-level language" by any consistent standard you could assign to that phrase.
Footnote: inb4 "ASM is not a language"
It has a grammar and syntax. It has a full-range of expression. Instructions that operate on data ("verbs") have "conjugates" regarding how that data is accessed, and often "adverbs" that do things like pre/post-increment.
Additionally, a given assembly language contains all other possible programming languages. Read that again carefully if you need to.
Anything you can write in whatever language you choose, can be written in assembly.
I consider the argument refuted.
Chat rant: 2016.02.04
jspark311 I really don't like that guy's outlook. His posts are reasonable, but he seems like he talks down on C for the very reason that makes C worthwhile.
I think very little of the "make all the things functional" and "C is a relic" attitudes, and I only read his posts because he trolls better programmers into posting comments that are actually good perspectives.
He talks about functional languages as if they aren't an abstraction over the very thing that he criticizes. IE, every language he likes has an interpreter written in C/C++. Almost as if he talks about his functional handcuffs as if they gave him more flexibility.
He also doesn't mention (or frequently glosses over) the fact that memory bandwidth is a finite resource, and copying redundant data around all the time is a horridly inefficient use of not only the memory volume itself, but the time on the bus required to access it.
His commenters even say as much: "Isn’t this a serious limitation?"
Sevilla sounds like a far more accomplished programmer to me.
And he himself says: "Fortunately, all C++ programmers have learned to live with “programming by discipline”"
Um.... that's called KNOWLEDGE AND EXPERIENCE. And while I would agree with the perspective that you don't need a chainsaw to prune a tree, I would rephrase it to say that powerful tools shouldn't be touched by people uncomfortable with powerful tools.
Because: you can, in fact, prune a tree with a chainsaw.
Also, You can't guarantee immutability on ANY computer with memory that can be written more than once. So the fact that his language doesn't allow variables to be written twice is indicative of a language that holds your hand and isolates the programmer from reality. Not good.
Easier to write it? Certainly.
Easier to debug? Probably.
Easier to read? Perhaps.
More powerful? No.
Smaller and more efficient? No.
And with regard to thread-safety: I locked my two children in separate rooms and then claim that they are getting along.
Think harder, Homer.
I should challenge him to write an arduino program with at least 3 interrupt sources. I assume that he is proficient with C/C++ because of his shit-talking. So he shouldn't have any trouble with the language itself.
See how his functional approach works in THAT space.
"I ran out of memory trying to sort a list of 10 things!"
"My ISRs are in a race-condition because copying my data took too long, and concurrency bugs ate my dick off ANYWAY!"
Concurrency is a hard problem in C/C++ because it is a hard problem in reality.
Retreating into a space where it is not a hard problem is just hiding behind a better programmer that solved it for you. And that means accepting his choices and trade-offs.
And that's reasonable. Who wants to deal with issues that have been solved already?
But from that cover, to then tell that programmer that his language is insufficient because it doesn't have native support for immutability and thread-safety underscores the fact that the complainer either lacks knowledge, or doesn't know that he doesn't know that the problem-space is far larger than he can see.
Chat rant: 2016.09.23
This is the link that started the rant. (The comment thread was quickly jacked by language zealots).
I couldn't blame anyone for disliking C. But the outright animosity towards it strikes me as anger at reality. You know? Like being mad that you are subjected to gravity.
It is the most-basal high-level language. It isn't going anywhere. Any lower, and you lose platform independence because you are writing assembly language at that point. Any more abstracted, and you lose low-level control of everything.
I would wager that >=85% of the loudest complaints about C come from people who tried it long enough to understand that they lacked the knowledge and/or patience to wield it, and never touched it again.
Is it dangerous? Yes. That's the reality of building things that operate at the nanosecond scale.