As for me, I like C because I consider it a "high level assembler", as a backend for modern programming languages like Nim which profit from the C compiler's strong code optimizations. If there is any new hardware platform, there usually is a C compiler, too. This makes porting source code really easy.
If you're C code is portable then you've chosen the wrong language. C is best when assembly would have been appropriate but you want to write something in a more maintainable, higher-level language. C shines when you need to optimize for a specific operating platform.
C is deceptive, though. It encourages a mental model of high-level assembler, but it's an assembler for an abstract machine, not the actual machine; and compilers are increasingly making the difference evident.
I believe the choice of C isn't really about "how computers work" as much as "how algorithms work", with C only providing a minimal toolkit of architecture-independent efficient high-level functions that allow for a simple mental model of how algorithms in higher-level languages work underneath, which is extremely useful in the real-world for getting a good overview of algorithm efficiency.
Another good reason is that C is useful as a sort of mid-level psuedocode. This pseudocode is useful for providing a mental model that allows you to make the leap from a modern high-level language to C to an assembly language much more easily than making the straight cognitive leap from a high-level language to the specifics of an assembly language or architecture.
C is actually "high-level" in most aspects and we tend to forget that because of newer languages with lots of bells and whistles. C gives you a lot over assembly: functions with (mostly) no need to worry about calling conventions, automatic variables instead of dealing with registers and stack frame offsets, expression-oriented syntax that facilitates nesting of many operations within a single statement, structured programming support instead of scattered jumps and a rudimentary type system around values, pointers, arrays and structs.
Nothing fancy, but it means that the language can be compiled in a straightforward manner without any runtime support and a programmer can easily have a complete mental model of it.
One great advantage of C (which was kind of mentioned in the article) is predictability of the generated code. Compared to a C++ compilers, a C compiler is much simpler. When you write a for loop, even doing something on a struct or some fairly "complicated" object, you have a fairly good idea of the machine code generated. It's also easier to go between the assembly code and the C code generally. In some applications like email or image processing, this can be valuable.
Agreed. I have used C almost every day for the last 25 years... And not only is the C more maintainable, it is more easily ported to new CPU architectures than assembly (complete rewrites in that case) -- and yes, it is a fast, low overhead language -- especially moreso when using the CPU vendors compilers over GCC since they already know the best way to optimize for their own architecture.
For big computers, C is good for systems programming because everyone else uses it and because of the titanic effort that has been put in to building really good optimizing C compilers. UNIX came along but when C killed pascal, IBM, Microsoft, everybody was on C's dick.
On small embedded computers, I think C is popular because it's so easy to build something that resembles a C compiler. The fact is, undergrad compiler classes almost build C compilers (some universities might actually go all the way.) You can almost build a yacc grammar that will read C and emit assembly. The small computer embedded vendors have a difficult problem, they need to provide tooling and they don't usually have giant piles of developers to sell to. So they dust off some abandoned "C compiler" they found in the gutter, add their hardware to it and call it good. At least that's my theory and I've seen some rough "compiler work" from some pretty substantial hardware vendors. In fact, if you're running a 16bit or smaller part or a weird part, I have yet to see a decent C compiler from a hardware vendor.
I have an old lapel button: C combines the power of assembly language with the flexibility of assembly language. Humorous, yes, but still true - it's a high-level, platform-independent assembly language that (used well) allows for creating all sorts of things great and small. I found it the perfect back-end to a Python front end, where the known problems of C could be minimized via control being done at the interpreter level and the compute-heavy work being done in C.
I guess, because compared with other systems programming languages since the early 60's, C grew out of language used to bootstrap compilers and its authors were happy with it being a kind of friendlier macro Assembler.
It's more that it's the most honest representation of the assembly/machine code. We can't really get closer to the hardware than the interface the CPU offers, and C then sticks pretty close to that (or a subset of it, I suppose).
It's the simplicity and power of C that I find attractive. I don't write it professionally at the moment, but I enjoy it. It's obviously not the right tool for the job most of the time for the reasons you give, but I miss its elegance.
I am a big fan of rust, but it's massive compared to C. I'd like to explore Zig some day.
Except that C isn't really the truth - Assembly is the truth. You can easily write code that is a huge abstraction from what the CPU is actually doing - for example, writing `float y = 1.5 * x` on a processor without a hardware FPU will generate a ton of instructions that one wouldn't normally think of.
Now, the abstraction layer that C provides is valuable, and C is indeed much more practical than assembly for most purposes, if only due to portability - but if the only reason for using C is to gain an understanding of the inner workings of the computer, without regard to portability or reuse of code, assembly serves that purpose even better.
"C has retained its popularity because the answer to the question what is the lowest level language I can code in without using assembly has always been C"
What a way to miss the point! There are plenty of languages between assembly and C. C wins because it's about as high-level as you can get before you start incurring run-time penalties.
reply