It's a tiny language, has easy syntax, and "undefined" behavior (which you don't normally run into) exists for a reason -- e.g. to avoid having to check for unlikely cases every time a heavily used function (e.g. memcpy) is called.
It's a tiny language, has easy syntax, and "undefined" behavior (which you don't normally run into) exists for a reason -- e.g. to avoid having to check for unlikely cases every time a heavily used function (e.g. memcpy) is called.
My point being, that it is a bit arrogant claiming that somebody isn't a fully qualified programmer unless they understand X technology. In my book you can be a fully qualified programmer (what ever that entails) if the only programming you have ever done is in Excel.
Are there equivalent examples between C and assembler? What sort of conceptual stuff is C missing that assembler clarifies?
By contrast, the average Python programmer couldn't debug into the Python internals if their life depended on it.
But you are correct that C by itself is not quite enough.
And, yes, knowing assembly sometimes do make huge difference as a programmer, but only in limited fields.
And that's fine, why does one have to understand an ancient language when they can interact perfectly fine with machines by using Python, Swift, Java etc?
That's why I included Java, C# or Javascript. If you can read those languages you can read C.
And it's not the language what they need to understand. C in itself is a fairly simple language, that's why I said that any person with experience in that family of languages would be able to read it straight away. What one should understand is how the computer is doing what you ask it to do. What does "create an object" mean, what is a "reference to an object", what are the heap and the stack, etc. These are concepts that are extremely useful and, as the parent comment said, almost required to know in order to be a full programmer and be able to understand what happens when you create your programs.
I've been doing C++ for more than a decade and had two tough experiences lately:
* I had to review a C project of several thousand lines. It's impossible for a human to understand if memory management is done correctly without weeks of deep analysis, so I had to resort to tools. The logic of the code is also hard to make out because of the memory bookkeeping.
* I was reading the open source code of a Linux program and had to dig deep into a couple of system topics and read the documentation for half a dozen syscalls to make sense of it.
For me, C is one of the hardest languages to understand, you're always zoomed in at 10x, looking at all the insignificant details of memory management, working with strings and arrays, etc.
I think that's what the parent comment meant with "reading (normal) C". The language itself is simple, because it only has the ifs, elses, and fors. Of course, given the simplicity of C the projects end up being complex because they have to manage a lot of things that other languages do for the programmer, but that is outside the scope of the language (i.e., you don't need to resort to the language manual to understand it).
In other words, the discussion is not that everybody should be able to dive deep into C projects and instantly know what's happening, and know all syscalls and everything. The discussion is that a programmer should know what is memory management, what is a system call, etc, which is practically synonymous to being able to read normal C.
{
while (*dest) dest++;
while (*dest++ = *src++);
}This is pretty much C specific. And side-effect ridden, at that :-)
I doubt the average Javascript programmer will figure that bit out, at a glance.
If you can read those languages, you can probably tokenize C fairly well, and parse a decent proportion of it. But only understand maybe a small fraction.
If the interpreter or VM used by any of those languages is written in C, someone still needs to understand it. Not to mention that it doesn't hurt to understand the internals of your chosen language if you want to make the most efficient use of it.
Doesn't hurt to know the internals, but one's time's limited and better spent on other endeavors. If I wouldn't be doing embedded I wouldn't touch C with a 3m pole, nor would I need to :) In fact my life's mostly C free nowadays and I'm quite pleased with that.
It's stopped evolving and can't really shine in any of today's domains.
It will still be around for decades, but mostly as legacy. I.e: not anything which is required to be learned.
There's also those that misguidedly use C when they shouldn't (e.g to speed up Python code). It's unfortunate, but such is C's siren song - mesmerizing one with promises of speed only to be dragged into the depths of undefined behavior.
Here's what I know:
* AI / ML can be done in many languages, but no one's seriously considering C, despite the performance requirements. C++ is sometimes used.
* self-driving companies are hiring for C++.
* Mobile is Swift / Kotlin with C++ for performance-intensive code where appropriate.
* Web is anything except C and C++ (thankfully)
* Game development is C++
* The enterprise has switched to web technologies or is still using Java/.net.
* The desktop varies, but it's mostly .net / Swift + Obj-C / C++, with the exception of gnome perhaps, which I'd argue is an anomaly.
C is still holding on in kernels and low level embedded, where it's expected that C++ and maybe Rust will continue to squeeze it.
Personally I don't care that much about the above two. Banging the same bits for decades gets tiresome.
I'd go into this more but I don't feel like explaining these things to people ad nauseum. C is one of the most used languages around the world, in new projects, too, and nothing you've said changes that.
Some of the things I listed are C++, which is a different language, which kept evolving unlike C and also unlike C is in demand today for all sorts of hot domains. The two can't be mixed.
But in a way, you may be right ... all the critical new lower level programs like web servers are now mostly written in Go, Rust and C is not favourably considered for them ...
> misguidedly use C when they shouldn't (e.g to speed up Python code)
The Python virtual machine itself uses C to speed up Python code. Python's compiler is even written in C instead of being properly self-hosted.
C has nothing to do with this. C is a quirky old high-level language which has nothing to do with underlying abstractions, i.e. with how the machine works.
If you want to learn what's beneath, you open a machine manual and read it.
You have to be a complete engineer because you take full responsibility for what you're doing. All your tools carry disclaimers in their licenses which absolve them of any responsibility if something goes wrong.
for LANG in Python, Ruby, Rust, Java, ... :
If $LANG has a bug, and because of that your $LANG program causes some harm to the customer's data, you can't blame $LANG.
If I'm in a situation that I'm somehow required to do something with Python, and something goes wrong, I can debug it right into the Python internals. If the problem is with how GCC compiled $LANG, I can debug that too, and I can drop to the machine level if needed