The cost of forsaking C
medium.com
medium.com
Want minimal syntactic sugar and a language that's not prone to feature-of-the-week hipsterism? C
Want to make tiny binaries for some obscure system with virtually no storage or RAM? C.
Want to know where every last cycle goes and explicitly control everything? C
Want to trivially import any of the huge array of existing libraries? You guessed it...
Want to do something you really shouldn't, and any 'sensible' language might attempt to stop, but is called for right here and now...
It's not the safest language, it's not the most expressive, but the syntax is small enough to hold in your head and the body of existing, available work is HUGE. I've been working in C for 15 years and, while I enjoy forays into other languages, it will always be my love.
You know what you get with C and it just works as you expect always. I always feel refreshed after writing C.
There are perhaps a few very minor enhancements I'd suggest, but I'd be very reluctant to open the floodgates and ruin it.
C is one of the few languages, along with C++, that revels in undefined behaviour. It can be very hard to reliably know what a C program will do if it's not written very carefully because there are so many constructs that look benign but which are technically wrong, and the compiler will mercilessly exploit in order to optimise your program into nonsense.
Actually - not completely true. I do like to look at the assembly from time to time for other reasons, but this is rare.
1) Diagnosing a crash which turned out to be the result of a 1 byte vtable pointer corruption bug in an older codebase, which turned out to be a bad static_cast in relatively removed code (a good case for boost::polymorphic_downcast!). Simply understanding which pointer was bad in the first place required looking at the disassembly - when you can't rely on your debugger's results thanks to optimization.
2) Figuring out the actual values of variables in crashes and crash dumps of optimized builds to properly root cause a bug, when the debugger gets confused - or simply aggressively inlined and reordered everything so aggressively that there's no sensible values to even display (so, most crash dumps.)
3) Noticing when the optimizer has reordered code "unexpectedly", alerting me to the fact that supposedly thread safe code is in fact nowhere nearly remotely safe and is in fact missing many memory barriers (possibly because their portable macros "helpfully" defaulted to a noop on whatever new and previously unrecognized platform I'm porting to.)
4) Noticing when the optimizer has removed or rewritten code in an "incorrect" manner, helping me debug code that would've worked if it hadn't technically invoked undefined behavior, so I can a) fix it, b) attempt to explain to my coworker that, yes, it's really undefined behavior, and yes, it's actually a problem (typically with a combination of citing the standard and linking INVALID WONTFIX-ed "bugs" in some compiler's bug database), c) be reasonably certain I've actually found the real root cause of a bug and fixed it.
Now, yes, I'll admit this isn't 100% of my debugging sessions. And perhaps I'm an outlier. My coworkers generally learn that I can (eventually) tackle pretty much any weird bug they might be struggling with and that I'm happy to help. All the porting I've done reopens a whole codebase's worth of wounds - latent undefined behavior that another compiler's optimizer didn't take advantage of.
But on the other hand, I've been lucky enough to never encounter a codegen bug in all the compiler and linker bugs I've found. So far. That I know of. And while "rare" by incidence, these are the debugging sessions that can eat weeks at a time for a single bug, when sufficiently nasty and novel.
I'm sure you could say that about pretty much any programming language: "The amount of terrible X in the real world is enormous". There are also plenty of clean, nice, safe C code around (and any other language), there's no need to over-generalize ("Almost no one else does").
But the damage is far greater in C. In other languages you won't have arbitrary code execution or privilege escalation just because the programmer is not careful. Nor will there be, in other languages, so many nondeterministic bugs that show up once in a blue moon.
Sure you do. Remember the YAML fiasco with Ruby? How about the thousand-and-one RCE issues with PHP? eval isn't evil for no reason.
No, it's possible to make system insecure with pretty much any language if programmer is not careful. SQL injection, cross-site scripting, cross-site request forgery and the list goes on..
There's bad code everywhere. Some languages make it a bit easier, but it's really not the languages fault.
If your best defense of a language is "well, at least people use it", that's a bad sign.
You think so? Every company I've worked for, or that I've known people that worked there, always enabled -Wall for their C and C++ code. Most OSS software compiles with all warnings enabled.
I think the issue with undefined behavior in C/C++ is extremely overblown, aside from fun academic examples like 'what does i++++i++ evaluate to' there isn't actually all that much undefined behavior or gotchas in C/C++. I would say there are less, compared to other languages I know.
You need to know that the problem exists in order to know that you have a problem. There are many C programmers who learned C back in the 1980s who don't even realize these are issues.
I'm still adding the compiler specific annotations to add format string checking to custom variadic logging functions in codebases I inherit, and finding multiple bugs.
Of course you want -Wall -Wextra -Werror -pedantic. ;)
There's nothing like the experience of trying to fix somebody else's code which compiled fine on gcc version 8.97 but which now fails to compile on gcc version 8.98 because the new compiler has some new warnings, which it's now treating as errors, and now fails to compile.
...and you've got stuff to do, and the program isn't even broken.
Well, it may be — that's one of the problems with C: you never really know for sure if a warning really matters or not. But man, there sure are a lot of them!
Last I checked he has a couple hundred points on the hacker news internet forums.
Also just last week I found and reported some undefined behavior in a major c++ package that's used by almost every player in as many as several industries. I don't expect it will ever make any difference in production, but it still snuck in.
void func(void *ptr)
{
uint32_t *ip = ptr;
ptr[0] = 123;
}Otherwise most every assignment after call to malloc would be undefined.
From C1X, section 6.3.2.3:
"A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined."
Though that is quite odd, since any pointer can be converted to void* , which only needs alignment to the char type. So converting from x* -> y* is undefined, but x* -> void* -> y* is defined.
>> uint8_t x[100];
>> uint32_t *y = &x[1];
And then dereference y, most RISC architectures will trap on the unaligned access. It doesn't matter if there is an intermediate void pointer or not.
According to my reading an intermediate void pointer allows the pointer casting to stay well defined. However this seems unsafe, even without getting into dereferencing, because implementations are allowed to store omit bits if they assume aligned pointers.
"A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined."
The resulting uint32_t pointer in my example is not correctly aligned for the reference type, so undefined behavior (e.g., a trap on RISC) occurs. What's an example of a statement in a "non-trivial" C program that is in common use but you think is undefined?
(1) I didn't say your example didn't demonstrate a violation, but it misses the point, because it doesn't invoke an intermediate void pointer:
"A pointer to void may be converted to or from a pointer to any object type. A pointer to any object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer."
(2) That was my attempt at coming up with a good example, but it seems, due to the above clause, the casting between incompatible pointers via void * is technically "legal".
Undefined:
int64_t a = 42;
void* p = &a;
int32_t* i = p;
printf("%i", *i);
int64_t a = 42;
void* p = &a;
char* ch = p;
printf("%c", *ch);
An object shall have its stored value accessed only by an lvalue expression that has one of the following types 73) or 88):
* a type compatible with the effective type of the object,
* a qualified version of a type compatible with the effective type of the object,
* a type that is the signed or unsigned type corresponding to the effective type of the object,
* a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,
* an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
* a character type.
73) or 88) The intent of this list is to specify those circumstances in which an object may or may not be aliased.
I still wonder if my snippet counts as undefined behavior, since it does dereference an "unknown" void pointer, which may have come from an incompatible object type.
BTW, the latest C1X draft is only at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
It counts as potentially undefined behavior - depends on what you pass in. NULL? UB. Pointer-to-uint64_t? UB. Pointer-to-uint32_t? Perfectly defined behavior! ...well, assuming we use ip[0] = 123; instead of ptr[0] = 123;, which won't compile as I've just noticed.
That said, there are some ways to construct pointers which are in and of themselves undefined behavior for merely constructing the pointer:
http://stackoverflow.com/questions/23683029/is-gccs-option-o...
More samples:
int a[] = { 1, 2, 3 };
int* b = a+0; // Perfectly defined/legal/normal
int* c = a+3; // Perfectly defined/legal/normal, just don't deference it (as it points past the end of the array)
int* d = a+4; // Undefined behavior. HAIL SATAN!
int* e = a-1; // Undefined behavior. Also apparently potentially caused optimization induced breakage in practice. HAIL GCC!Well, it works as defined in standards. It's just not every programmer knows what to expect. C is simple, yet powerful language and with powers comes responsibility. It's not like you can throw some libraries/modules/objects (or whatever it is in other, safe languages) together, upload to server and call it a day -- static testing, debugging, unit testing is a vital part of any semi serious C project.
It's the complete opposite of waiting for a feature to appear in the compiler.
Every language works just as you expect if you have the right expectations.
"C is memory with syntactic sugar." Dennis Kubes
So... you compile with optimisation switched off?
For instance, when writing a scalar-processing loop over a fixed length array with no dependency between iterations you can reasonably expect the compiler to convert to SIMD instructions and do some unrolling. It's not too difficult to check the binary that this happened, and if it doesn't happen you just write it yourself with intrinsics.
I often think of C + compiler's optimization passes as a "scripting language for assembly".
C++, D, Rust, ...
> Want to trivially import any of the huge array of existing libraries? You guessed it...
If C can talk to it, so can anything else. Granted, having the preprocessor means no bindings, but C++ has that too.
> Want to do something you really shouldn't, and any 'sensible' language might attempt to stop, but is called for right here and now...
C++, D.
Want undefined behaviour? C. Want segfaults? C. Want memory leaks? C. Want memory corruption? C. Want to write insecure code? C. Want to write your own containers? C. Want Go's approach to generics? C. Want to spend 3x as much time writing code as a comparable C++ solution (not to mention more productive languages)? C.
I've known C for 21 years now. I just quit a job as a C programmer for embedded systems. If I can help it, never again.
Want all of that and a whole bag of inconsistent design choices? C++. Because, yes, one day you will meet a C++ codebase which is a mixture of "forbidden C++" and "modern C++".
Perhaps so, but reading it back takes 5 times as long.
Coming from Python and dabbling in C for embedded software, this is the one that gets me the most. It's so frustrating to be spending hours doing something you can do with one line of the regex library in Python...
The conversations that occur here generally seem much more structured.
Engineering is a life and death business more often than people think; it deserves people who feel strongly about it.
As an aside, I think the rules about trolling and personal attacks are pretty clear and easy to enforce. What I'm specifically concerned about is that those rules are evoked outside of the spirit in which they were created to attack emphasis in general. In fact, most of the discussion here is in clear violation of "Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them." but obviously we rightly care a lot about this topic and, since people are acting like adults, no one needs to tap on the poster so to speak.
I appreciate that the majority of people in this forum express their opinions in a highly productive manner void of animosity, as you've just demonstrated. The previous's user's remark "Worst argument so far." did not convey this spirit. Whether intentionally or not, antipathy and pure negativity do not bring out the best of people in online forums. It is my hope that those are two things which this community seeks to discourage, but not all freedom of expression. This is how I interpreted the comment which sparked your initial response.
Which everybody here knows and nobody doubted. So, a big duh!
What the parent means is with Python you don't need to go and install one, adjust your makefiles, etc. Regex are right there in the standard library, and things that are not are immediately usable in just a "pip install" away.
Do people actually use pip when you can just use the package manager of your distro?
However it doesn't give you the control or the performance of C without some serious work, some of which is usually work in C!
On top of the additional testing, you also will have a performance problem at some point after success. And then people will discuss or even plan for a rewrite in a more performant, language. But we all know that rewrites usually fail to materialize. PoC's turn into products, products turn into companies, and companies bottom lines can't generally spare time and money to rewrite the entire service.
I'm not advocating for C, but I wouldn't put Python up as a comparable thing.
As a noob C programmer, in my programs segfaults often occur along with undefined behaviour (which is much worse, as your program will silently give the wrong output).
While in Python, you'd get a traceback which is much easier to debug.
> Requiring a massive set of tests to actually validate your code.
Both require tests to validate your code. Sure, static typing can verify some trivial mistakes, but they can't check that array accesses are in bounds, integer overflow, etc.
> While in Python, you'd get a traceback which is much easier to debug.
Well, C's segfault will also generate core dump, which is essentially the same thing as Python's traceback - it tells you where the program crashed.
C code that compiles can and does blow up at runtime.
There are languages whose type systems do go a long way toward minimizing the risk of this happening, but C is not really one of them.
I personally wouldn't choose either language for a new project.
C is not typesafe either, and blows up for other reasons at runtime.
Overall though I think what you may be seeing is simply the stratification of software development; what began in the 70s and 80s has come to fruition. There are different planes of existence, like thermoclines in the oceans. A developer may (and is likely to) live in one forever, without crossing above or below. Each has its purpose. While I wrote my own database and rendering engines in the 80s as part of applications development, I wouldn't dream of it today unless there was a very, very good reason. Same goes for network stacks. Or math libraries. Memory managers. Etc.
Sure, coming from the Python ecosystem, you will feel as though there is a shortage of auto-pilot-like assistance, but you must realize you are in a very different world now - Embedded work is (frequently) focused on predictability, responsiveness, efficiency, and even moreso with realtime work. You are the engineer in charge, and all the safe boundaries and cushions of the interpreted language world are now missing. Want to REALLY feel naked? Drop down to assembly on any platform and try to emit a simple "hello world." For those who have never done so, it's a humbling experience but rewarding.
Remember that C was designed as a "universal assembly language", easily portable to different architectures and close (enough) to the metal so the programmer can have full control over the machine. Best analogy I've heard: C is like a chainsaw - used carelessly one can cause enormous damage and destruction, but in the hands of a skilled/experienced craftsman, very clever solutions are possible.
Mostly because I'm used to one single place for libraries (PyPI) and I don't know how to find (and evaluate) libraries in C. I also don't know if they'll run on my MCU or how much RAM they require. I have found one or two embedded regex libraries, but they were very limited in what they could do or failed some other criterion.
Besides, that was just an example, it's just death by a thousand cuts with similar things one after the other.
you can replace C with any language. you're evangelising about the toolbox you know instead of learning about the hammer you are familiar with and don't want to learn how to operate
You probably wouldn't do that in Python; the regular expressions module is part of the language.
The Lua docs provide some examples of integrating Lua into C here - https://www.lua.org/pil/24.1.html.
If your target only has two KB of RAM, Lua is a no-go, I guess. But skill-wise, I can highly recommend it. The reference manual is very well-written, the Lua language itself is very nice and easy to learn, and Lua's C interface is very pleasant to use; and again: the documentation is very good. (Also, the community is very friendly!)
If you ever take a shot at it, the Lua Users Wiki (http://lua-users.org/wiki/) is a good starting point.
Throw in the level of control with sprintf() and there's a pretty clear win.
What is easier with C++ ( and most scripting languages ) are things like combinators and regexp.
As is *cat being O(N) with respect to destination length.
So easy that there's been constant flamewars over nonstandard alternatives such as strlcpy, strcpy_s... https://news.ycombinator.com/item?id=6940368
Or if being verbose is desired, do you want to do a job for a computer that you are not suited to do but the computer is?
I want optimal syntactic sugar.
Like Rust or C++ templates? I prefer C syntax over the "optimal" alternative.
(I know there are some "tricks" you can use to make smaller Rust binaries by chopping things out, but of course the same applies to C. For example, I can take the C binary and just truncate the file down to 2230 bytes without breaking it)
For more: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...
C binaries are small because they're assuming you've installed what is ultimately the C runtime on your system (libc).
The tricks you describe are just changing the compile options to those that C uses by default.
on top of that you can apply the same tricks as C; e.g. by running strip, truncating the binary, writing a linker script, etc.
Can be solved by not doing stuff that are considered as undefined. Think of them as the standard's say of saying "don't do that". It's quite easy to do in most cases.
> Want segfaults? C > Want memory corruption? C > Want to write insecure code? C
There is absolutely nothing in C that makes it more prone to these in comparison to other languages. Moreover you can easily solve these by using an implementation that protects you. (such as one of the multiple C compilers that guarantee to produce safe code without UB or the sanitisers in gcc and clang)
> Want memory leaks? C
Can be easily avoided by avoiding dynamic memory allocation. Moreover nothing stops an implementation from using a GC.
> Want to write your own containers? C
This applies to all the languages as none of them happen to have an implementation of every container in their standard library. It is true that C lacks that in comparison to some other languages, however implementing the common ones (or using a library) is an extremely trivial thing to do.
> Want to spend 3x as much time writing code as a comparable C++ solution (not to mention more productive languages)? C
You must be quite the shitty C programmer to need 3 times less time to write something in C++.
I have a list of "don't do that" rules. I still do them, usually by accident.
> There is absolutely nothing in C that makes it more prone to these in comparison to other languages
If you believe that, then there's nothing I can say that will change your mind.
> Moreover nothing stops an implementation from using a GC
Many applications can't use a GC. For tiny systems, forget it.
> none of them happen to have an implementation of every container in their standard library
That completely sidesteps the fact that in pretty much every other language the containers one would like to use 99% of the time are implemented in the standard library or the language itself.
> You must be quite the shitty C programmer to need 3 times less time to write something in C++.
Only a shitty C++ programmer _doesn't_ write code 3 times as fast as they'd write C.
I've worked in numerous languages and platforms, even changed careers from programming (graphics) to film and television. But I'll always be a C programmer.
However, for me, C falls down on large projects. I know there a lot of hate on objects lately, but the complexity of a project decreases while the maintainability increases when you use properly designed interfaces. You “force” the new guy to do it right because the interface makes it obvious. I know there are ways to enforce encapsulation with C, but I’ve never worked on a (large) codebase where this has been successful.
I try to organize into specific components and piece them together into a sequential or threaded or both model, depending on what I do. Of course, it is specific to what I do. But there are large C projects that are successful - for example, Linux kernel.
C++11 really does put that to rest. Move semantics basically enable complete avoidance of manual memory management. There are many other powerful and convenient aspects, but in C++11 and on managing memory essentially goes away. I essentially never allocate memory explicitly.
Depends on what you do, I guess. I process huge image sequences and have them run (play at least) in real time. I cannot afford to not allocate memory manually. In fact, I have to and I have to manage heap myself. I also have to manage thread affinity, in order to have threads (producer/consumer) share L2 cache to get the speed I want, and all that on multiple processors.
Sometimes you must do that manually.
You say that, but I deal with almost the exact same things. What I mean by manual is something like malloc where the freeing of memory is manual. Sean Parent would call this 'no raw pointers'.
For starters, the fact that memory allocation is even an issue seems odd to me, I'm not sure why you wouldn't allocate large chunks of memory rarely.
Even if there are OS specific calls I'm making to deal with special memory, I make sure it is wrapped with some simple class or struct that has a destructor and likely a move constructor. Alignment issues can be wrapped as well, then there is no doubt who owns the memory, who frees it, and where/when it is freed. I've never seen a situation in which raw malloc/free are necessary or any control is lost using C++.
I doubt you suddenly want to use C++ still, I'm willing to bet you know C extremely well, but at least realize that your choices are not based off of technical reasons.
One thing is sure though. You're right most of reasons aren't technical. I'm very confident about what I know and what I don't know in C and I don't have to second-guess (usually) what I want to do, because my experience lies with C. It's a subjective choice, but also a technical - since that knowledge and experience is my technical asset. It's not like you can't do something in C that you can't do in C++. In fact, you can do it almost the same if you want to, but with C++ you would be a better fit if you follow C++ idioms, which I haven't picked up over the years (especially after STL cambrian explosion) and something I think I won't in the near future. Reason is simple. Everything I do, I do mostly alone and so far C has been good to me. I venture into other things, out of curiosity and sometimes necessity, but I always kind of fall back to C. Sometimes it's due to the fact that I know of top of my head how to do something quick (which I often need to) without resorting to googling or I don't know how to make it run quick enough since I'm not intimate with the language (not C++ in this case, but in general).
while (*++targ = *++src)
;Kinda like with everything else related to C!
The problem is, it's also up to the programmers who worked on my codebase before I did. I would never write that atrocity, but I've come across that atrocity quite a few times in code I needed to modify.
(but usually generates compiler warning without an additional set of parentheses)
Unless the data is user-generated, in which case you might have a security issue on your hands... :)
I particularly want to take issue with the claim in the original post that "C helps you think like a computer". C's machine model might have been a good model for the machines at the time at which it was developed, but it hasn't been an accurate model for a long time. A simple example is C's assumption that memory is flat and all locations have an address. With multiple layers of caching and nearly a couple hundred registers in current CPUs this is far from the truth. If you think programming in C is programming at the machine level you are deluding yourself.
Add to that the aggressive optimisations performed by modern compilers and that mental model breaks completely. It may be a good conceptual model, but it's not the model under which your program actually executes.
However, even programming in assembly keeps you very "far from the truth", since modern CPUs are very complex beasts internally and that complexity is mostly not visible in the ISA.
Few things have made me more nervous in my career than seeing a ISR making use of C++ standard library features. When I asked the engineer how they were sure this was safe and worked under the covers, I was immediately dismissed as "the compiler takes care of all that." The project only ever worked at -O0 and was still buggy. The engineer blamed the hardware.
Could you elaborate on this? I thought at least speculative execution was handled internally in the CPU and essentially not visible to the user apart from the performance impact?
I’m not sure what you refer to as out-of-order execution, is this execution reordering within the C compiler?
> If you throw in interrupts or threads, you know you must tread cautiously in C.
Naturally, yes.
I wonder when we'll get an instruction set that gives us fine-grained control over the different levels of caching, or even the ability to create FGPA-esque microcode functions, etc. Compiler writers could have the time of their lives with such an ISA.
I'm not very experienced with GPU programming, but my understanding is that the programmer has more control over memory locality there.
Another point to remember is that CPUs have coevolved with programming languages. I think if languages tried to expose more detail in their machine model, ISAs might evolve to match this.
Finally, hardware designers mostly aren't programming language people, and programming language people generally haven't been interested in languages in the same space as C (though that is changing.)
Decisions like that and x86 is why stack operations are still dangerous despite B5000 (1961) having protected stack and MULTICS (UNIX/C predecessor) having reverse stack immune to overflow. C kept the shitty PDP stack instead of MULTICS for performance. Reverse stack on x86 still has performance hit due to that decision. It's why Itanium did shadow stack in hardware.
Not clever design or forward thinking. Just making it work on a PDP with long-term problems following.
Uh ... http://ee.hawaii.edu/~tep/EE160/Book/chap14/subsection2.1.1....
One of the secrets behind C’s success is that just about any machine architecture has byte-addressable random-access memory. Moreover, pick just about any pair of machine architectures, and they differ in their register structures. By excluding registers from its computational model, C has hit the sweet spot in being close to the machine, yet not too close. So there is no place for LOAD and STORE in C’s computational model, while the assignment operator is an operation on random-access memory in the presence of an unspecified complement of registers.
Similarly, you can find many C features, like ++ and +=, mirror PDP-11 instructions (see https://en.wikipedia.org/wiki/PDP-11_architecture, double-operand instructions for instance)
Finally the PDP-11 had 8 general purpose registers, with two taken for program counter and stack. It seems that main memory loads cost about an extra cycle. So register allocation was not a pressing issue. There aren't enough registers to make sophisticated register allocation worthwhile, and you don't pay a high penalty on a register spill. This is in contrast to all modern machines (e.g. current Intel chips have 192 registers internally and a cache miss can cost a hundred cycles [http://stackoverflow.com/questions/4087280/approximate-cost-...)
I'm coming to the same conclusion as nickpsecurity: C was designed specifically to run on the PDP-11, taking advantage of its instruction set, and we're still paying the price of those decisions.
It's interesting to imaging what a better low-level for, e.g, the Parallela Epiphany-V currently on the front page would look like.
https://www.parallella.org/wp-content/uploads/2016/10/e5_102...
Highlights:
- 64MB(!!!) of on-chip SRAM - 1024 processors - 64 registers
Further, C helps you think like a particular evolutionary path of computer, and the language and architecture developed mostly in parallel. It's like saying that giraffes have long necks because they need them to reach the tall branches.
I think there are a couple of ways that it could be argued that "C helps you think like a computer": most CPUs have been designed around running C code quickly and the oddities of the language force you to think like the compiler (which has both positive and negative aspects :/ ). For that matter, things like UNIX and POSIX make more sense if you underderstand C (and vice versa) and there are multiple complete and fairly popular open source operating systems you can examine that are written in C (and the mailing lists of these operating systems can be excellent places to learn a bunch of low level stuff). On the negative side (as you mention), I think it is very common to think of C as a lower level language than it really is (I'm planning on learning Ada, which it sounds like has more low level features, although still not the same as learning CPU architecture).
C forces or encourages you to learn a lot more about everything than other languages, which not a great thing if you just want to write a reliable program but isn't such a horrible deal if learning such things is part of the point. D, Ada, and to a lesser extent Rust seem similar in some respects and with significant benefits but without the easily accessible operating system projects (so far, that I know of).
So I guess my addition to that excellent post would be that if you are going to learn C you should get involved with an OS project. The BSDs are particularly good for this due to being more integrated systems and slower moving with more design consideration given to new features than in Linux. I'd personally recommend NetBSD, where the tech-* mailing lists are high quality and fairly low volume, but any of them should work well.
There's also more serious efforts: https://www.redox-os.org/ has made tremendous progress in a relatively short period of time, https://robigalia.org/ is an extremely interesting effort for Rust on top of seL4.
In case it wasn't clear, my "to a lesser extent Rust" comment was just about my impression that Rust can more easily be used without worrying about optimization level details vs. D or Ada or C. Which is a good thing if true since Rust can also deal with the low level stuff, although possibly it is just my mistaken impression (I only actually know C out of these languages).
I do think that you, overall, need to care less about optimization-level-details in Rust than in those other languages. But that's because we've made it so that the default ways you do things are already plenty fast; the idea is that the nice way of doing things is also the fast way of doing things, so there's no "well, looks like I can't do it how I want, time to replace it with something gross but performant." Of course, this can still pop up from time to time, but it happens more rarely.
Also, it can't be denied that there will always be areas where the exact control of memory layout that C gives you is not just nice-to-have for performance reasons, but a prerequisite for a good implementation or understanding of some algorithm.
Neither of those points, however, mean that C is the only suitable language imaginable for doing low-level work, or that the past forty years of programming language research are irrelevant to the spaces that C excels in. I think Rust shows quite succintly the immense value of the combination of an expressive type system and C-like zero-overhead abstractions.
Learning C, like learning some assembly languages, to some extent is probably necessary if you're serious about understanding computers, just to understand what's going on. But when it comes to actual use in production systems, I am glad that we are seeing serious alternatives to a language so prone to simple bugs as C. Think of all the time and money that have been lost to buffer overflows and segmentation faults.
The syntax of the language is also designed to help the compiler writer and not the user – think of "declarations mirror use", the irrelevance of the order of type specifiers, etc.
Err, I would agree with the statement that the syntax of C (mostly) favors the compiler writer, but "declarations mirror use" is decidedly not a good example for a couple of reasons:
1. The grammar for type declarations is actually quite complicated[1]
2. Agol, which inspired C's type system, actually had a much more "compiler friendly" type syntax[2]. C's syntax is designed to be more programmer friendly.
3. Dennis Ritchie makes it pretty clear that "declarations mirror use" was intended to make use and declarations visually similar, which implies that it was done for the benefit for the programmer[3].
[2] http://www.csci.csusb.edu/dick/samples/algol60.syntax.html#5...
[3] "Analogical reasoning led to a declaration syntax for names mirroring that of the expression syntax in which the names typically appear...In all these cases the declaration of a variable resembles its usage in an expression whose type is the one named at the head of the declaration." from http://www.jslint.com/chistory.html
In my view, a "user-oriented" declaration of an array of pointers would look like `pointer[10] of int`, and not `int *arr[10]`.
This is pretty close to Pascal syntax already: `array[0..9] of ^Integer`, where ^ is pronounced 'pointer to'.
Pascal is a language that is genuinely easy to parse; it's designed to be LL(1). C is not; in particular, typedefs effectively introduce keywords, and the easiest way to parse C is to inform the tokenizer about typedefs as they're found so the parser can disambiguate things like `a (b);`; this looks simultaneously like declaring a variable and calling a function, depending on the type of 'a'.
(they don't look the same, but you can use either to define record/structure types or enums, for example)
int main()
{
foo(bar);
foo * bar;
}
The situation doesn't come up in Pascal because variables go in the var block (starting with the 'var' keyword) and functions and procedures both start with keywords ('function' and 'procedure').
It never occurred to me to put variables names inside parens in a declaration when I did C, though. But OF COURSE it's legal obfuscation.
As stated elsewhere, I don't know why C had to screw up Algol's syntax so badly. I guess K&R liked curly braces much more than BEGIN/END, and why stop there, once you get going. Maybe somebody had a love affair with APL???
Using the same precedence and associativity in declarations and normal expressions doesn't really help the compiler writer though, so I'm not sure how this supports your point. If anything, it complicates the parser by making it harder to decide if a given sequence of tokens is a declaration or an expression (e.g. the classic "a * b;" problem).
> In my view, a "user-oriented" declaration of an array of pointers would look like `pointer[10] of int`, and not `int *arr[10]`.
It sounds like you're saying that C's type syntax isn't easier to read than other, similar, possible syntaxes. On that, I completely agree (in fact, I think C's type syntax is horrendous). However, that's orthogonal to the issue of Dennis Ritchie's original intent when designing C. From his writings at least, it seems like he wanted to make it easy for the programmer to reason about the syntax and I'd even argue that he took steps to complicate the compiler to accommodate his chosen syntax. I'd also argue that he failed horribly in accomplishing his intention and the syntax you're describing would have been much easier to read.
Not rocket science, obviously, but the original statement was that C types were designed to be easy to parse, which clearly isn't true. If the types were prefix or postfix, it'd be trivial to build the trees in a recursive descent parser.
And remember declarations can be arbitrarily complex. How do you declare a pointer to arrays of pointers to pointers to arrays? In free prose.
If you look at another old language, Ada, you'll find much more precise control.
In theory that's important, in practice you rely on implementation-defined behavior and put it behind a layer of macros. It's not perfect but it works - low level capabilities are not the problem in C.
Lack of high level abstractions make scaling it up and maintaining a PITA.
https://commandcenter.blogspot.com/2012/04/byte-order-fallac...
Do you know which non technical advantage C has? Multiple implementations. Don't like gcc, use clang. The Keil compiler has a certain bug that screws your project? Use IAR. And so on.
That is one thing. Another thing (at least at the company i work for and the ones i know) is, companies that write code for infrastructure or machines that need to rung a looong time won't ever trust a language (and toolchain) that comes in versions and not in IEEE standards. That may or not be stupid, but it is the reality i've seen so far.
P.S.: Before someone says C only NOW has multiple implementations, yes, at some point in time that was true, but i was VERY easy for compiler vendors to implement a C compiler (speak ROI). Time will tell if this will be true for Rust as well.
The Rust team has a very high commitment to stability, and does way more to maintain stability than any other language/compiler I know of (by testing new versions and potentially-breaking-changes against the entire ecosystem)
> still don't (seem) to understand the non technical problems it has.
Just because multiple implementations of Rust don't exist (there are a couple but nothing 100% feature complete iirc) doesn't mean that the community doesn't understand the need for it. Alternate implementations are hard to write and take time. The language is still new, but work is being done towards speccing it (e.g. the unsafe code semantics work being done right now). Note that most languages have gone for years without getting a proper spec or alternate implementations. This is an advantage C has over Rust, agreed. It's usually not a dealbreaker, though.
Yes, but my experience is that they don't seem to manage generating the kind of trust needed to get my peers to give it a serious go. It's a purely social and subjective problem.
>Just because multiple implementations of Rust don't exist (there are a couple but nothing 100% feature complete iirc) doesn't mean that the community doesn't understand the need for it.
As i said, it SEEMS to be so. That means that it is a subjective impression my colleagues and me get. It is the job of the community to generate trust, not the (potential) user's.
>Alternate implementations are hard to write and take time.
Yes, see my P.S. Time will tell if it's worth it to compiler vendors. C made it easy for them right from the start.
>Note that most languages have gone for years without getting a proper spec or alternate implementations. This is an advantage C has over Rust, agreed. It's usually not a dealbreaker, though.
Not a dealbreaker for whom? In the infrastructure and big machine business you will see C, some C++ and Ada. All standardized.
If the Rust community wants to offer an alternative for C, C++ and Ada, AND want Rust to succeed as an alternative, they need to understand that trust (in the toolchain) is generated in different ways in different industries.
Sure, there will be some cases where you absolutely need a standardized language. And Rust won't work there for a while at least. But that's a far cry from the picture painted in the original post.
Yes, and that is why those industries will choose to ignore it for a while at least.
Chicken and egg.
> though I suspect multiple implementations will come from elsewhere since we already have a couple partial ones)
>Rust already has lots of folks from other industries trying to use it
I'm not up to date. Input would be appreciated here.
As for specification, https://github.com/rust-lang/rfcs/pull/1643 is what's currently happening, i.e. specifying exactly how unsafe code behaves (this is more important than specifying the rest). But the rest will come.
As for the industry, https://www.rust-lang.org/friends.html
What are you talking about? There was a C standard because so many groups picked up C. The Ada mandate actually reduced its uptake with a bit of a rebound latter on when the tech itself was better (esp compilers). C++ got uptake before a standard plus fed into the C standard. So, no, the lack of a standard isn't stopping adoption by industry outside select firms that won't pick up tech unless it has a standards document which often isn't even accurate.
What industry does care about are compilers, IDE's, existing libraries, available talent, ecosystem, who they can pay for support. These things aren't at a level they like yet. Adoption stays low.
Note: Most infrastructure is written in C due to talent and compiler availability more than anything. That's what most embedded people tell me.
As for the rest, i agree.
I'm all for this but I really don't see how Rust's stability can hold a candle to the international standards committees that govern C and C++ (not to mention the investment from the big tech companies in developing and implementing these standards)
That's an orthogonal issue; that's adoption. More adoption means more stability, regardless of whether or not the thing has a standards committee.
Of course Rust can't hold a candle to the level of adoption C has.
> as much they still don't (seem) to understand the non
> technical problems it has.
Yes, for most developers this is true, but not all (see post above). Try looking at it from my perspective. If i suggest to my peers to give Rust a (serious) try and evaluate it for use in a project, this "hardly a priority" generates the impression of "we don't care right now, maybe someday". So they say "fine, i will give it a try in x years, when multiple implementations are available. It the meantime we will wait and C.".
So basically, chicken and egg. Again, the Rust community needs to understand what kind of impressions they generate vs. which impressions they want to they generate.
Update: Just to make that clear, i have to look at it from the perspective of an industry that produces infrastructure and complex, big machines.
Update 2: Fixed typo.
Interesting, but if you try to see the perspective of the Rust developers, they're a relatively small group trying to first develop the strongest language possible, after which other implementations will rise in priority. The idea is, it's better to develop a great language first and focus on other priorities later, rather than having a mediocre language with many implementations. Nonetheless, they're taking the necessary steps.
Agreed, but when is Rust done? 1.0, 2.0, 3.0?
Why does the Rust community talk more about adding optional garbage collection than IEEE standardization and alternative implementations (for example for gcc)?
You see, there's always this "one more feature" before it is a "great language".
If you want to sell it as a C alternative/replacement and keep going this way, it will be neither a technical nor a spiritual successor.
What? There is only one person talking about that, and that's me, and that's pretty low priority right now. There are three people total who are working on it (I worked on the higher level design, and felix/niko/I will implement bits of it at some point) and I don't think any one of us is currently doing anything here.
OTOH there is a whole group of people actively working on standardizing how unsafe code is supposed to behave. There are pushes for standardization elsewhere too, though unsafe code is the more pressing one since that's where actual UB can happen and that's where you need a standard the most. There's a group working on formal verification as well (which could produce a standard as a byproduct). Not sure if there are plans for making it an IEEE standard, but a standard it will be.
Standardization is a topic that crops up pretty regularly in discussions. Optional GC is not.
The type system is still in flux with specialization and a bunch of other type system changes on the horizon. These don't affect language stability, but they do affect how the standard would look since they may completely change how you describe the type system. Starting work on a complete standard right now doesn't make sense with these bits missing.
Edit: it's also not "optional garbage collection", really, it's just hooks so that it's easy to write your own GC, or, more importantly, integrate with another one. Rust is getting a lot of attention from folks wanting to speed up portions of their Python/Ruby/whatever codebase, so having these is important.
Software engineers these days are so lost in abstractions and design patterns that they forget that at the end of the day a program is just data, and a set of operations that transform that data. There’s huge value in writing code that does everything explicitly from top to bottom, both from a readability, and from a debugability standpoint. Instead, these days, software is designed using UML diagrams and OOP concepts while pretending that objects are ideas that float in some abstract disconnected space. All in the name of concepts envisioned by people who write books instead of programming, and who never saw even a glimpse of a problem you’re trying to solve.
Languages like C will never become obsolete. There’s always a new frontier of hardware that needs fast, tailored software. Few years ago that was phones, and watches, next it might be tiny implants. Anybody who thinks languages like C is obsolete should ask themselves “why was my Comodore64 more responsive than a PC i bought in 2016?”, or "why is my dual-core Android smartphone with 1GB of RAM barely usable after a year”. Modern languages and programming practices have this amazing ability to completely negate the massive progress hardware has made.
ObjC and Java
>>Anybody who thinks languages like C is obsolete should ask themselves “why was my Comodore64
Assembly and Basic.
ETA: it's probably worth put scare quotes around "resource constrained" when talking about Android and IOS but phones were dreta's example.
> ObjC and Java
To defend the parent's point, Objective-C is a pure superset of C. And there are quite a few frameworks on the Apple platforms that are pure C (not Obj-C), e.g. CoreGraphics, CoreAudio, ImageIO, OpenGL, etc.
You have to keep in mind that this is a very simple piece of software. I wager you that using things like templates made the code unnecessarily harder to understand. I’ll also wager that by using templates he made the code harder to scale, since any remotely complex template, just like an overused base class, eventually becomes a set of special cases, or a set of specialised templates which defeats their purpose in the first place, and makes your code a nightmare to step through.
This is a typical example presented in a talk. It doesn’t reflect any large real-world software, where complex language solutions (useful ones, not the ones in C++) could actually benefit the programmer.
Was pretty eye opening video to see that, that some of those complex looking instructions with a modern optimizing compiler can be surprisingly neatly optimized away.
BTW, if you want to run GEOS faster, get an REU and let the DMA transfer fun begin. This is 2016 after all; you must keep up with the times :)
Not because of C; that's for sure. The two biggest reasons are:
1) Your Commodore 64 is doing at least a couple orders of magnitude less actual work. This has less to do with language choice than it does with a programmer who is fully in touch with the problem to be solved and can identify unnecessary work to eliminate.
2) Your Commodore 64 is effectively designed in a way that prioritizes latency over throughput. Pipelines and buffers are small-to-nonexistent. When you read the joystick port, you sample the state of that joystick at that very microsecond; you're not asking one microcontroller to ask another microcontroller to start thinking about sending the input it sampled 10 milliseconds ago. The worst-case latency from changing the video data to seeing it on screen is measured in lines, not frames (assuming a low-latency display like a dumb CRT). Virtually nothing is asynchronous. Systems aren't built that way anymore because we want to be able to push massive amounts of data through subsystems that can't all run in lockstep to one fast master clock, and that means lots of buffering and burst transfers.
I understand that computers worked differently back then, and that software usually had full control over the machine, but please, don't talk to me about buffering, etc. when we're talking 6502 versus an i7, or an A8. I understand that input and output aren’t instant these days, but that’s an order of tens to hundreds milliseconds of delay. It doesn’t explain why Visual Studio takes tens of seconds to compile “Hello, World!” on a 16 core processor. Or why your Chrome tab eats 600MB of RAM.
Since you want to talk about buffering and built-in input delay, here’s a comparison of text editor performance:
C has three fundamental issues:
1) How big is it?
2) Who owns it?
3) Who locks it?
C's lack of help in dealing with all three is the main cause of most memory-related program bugs. I once tried to fix #1 in a backwards compatible way. See [1]. After much discussion on some mailing lists, there was general agreement that this was technically feasible but not politically feasible.
(I once had hope that Rust would replace C, but Rust has gotten too fancy, with too much input from the functional programming people, the template enthusiasts, and the type theorists. Rust isn't bad, but it's at least as complex as C++.)
[1] http://www.animats.com/papers/languages/safearraysforc43.pdf
Yeah, i remember using the Mac OS written in Pascal. Strangely enough, i remember it being buggy as hell and crashing pretty often (no memory protection at all).
Also C standard library cannot be implemented without using Assembly, unless one makes use of extensions not defined in ANSI C.
If I was talking about inline Assembly, which Turbo Pascal supported and to this day still isn't part of ANSI C, I would have said so.
The only times I actually was forced to use inline Assembly was to optimize graphics rendering and create a mouse device driver.
Both of them were a one time project.
Once upon a time I used to have some fun asking C devs for features not available in Turbo Pascal, while at the same time showing off all the safety and large project features that Turbo Pascal had and C to this day still lacks.
Back on those MS-DOS and Windows 3.x days there wasn't any feature that C compilers had and Turbo Pascal didn't had a similar feature.
program demo;
uses Dos;
var
regs : Registers;
begin
regs.ah := $02;
regs.dl := $07;
MsDos (regs); { Beep! }
end.The latter sentence sounds like a non sequitur.
Rust has gotten too fancy
By "templates" you mean macros? If so, how should a language implement the functionality that's currently delivered by macros?
I'm asking because I'm thinking about adding HKTs (higher-kinded types) to Rust.
> it's at least as complex as C++
- The functional control flow style, where everything involves closures, is much harder to understand than imperative control structures.
They're not opaque. Templates are more opaque because of the lack of self documenting bounds, perhaps (i still wouldn't call them opaque, just more so than Rust generics)
This is the millionth time you're repeating that garbage about imperative control flow. It boils down to a use of closures in a few stdlib functions. We've had this argument before, the essence of your point is that it is different from C. Of course there is a learning curve but that is there the other way too. Once you get used to it the control flow is pretty straightforward. And in most cases you can avoid the closures and write your if or loop manually.
Type Option. The 2014 version.[1] The 2016 version.[2]
(Coming soon, the "?" operator.[3])
Here's an example of excessive cleverness [4]:
fn main () {
let number: f64 = 20.;
// Perform a pipeline of options.
let result = Some(number)
.map(inverse)
.map(double)
.map(inverse)
.and_then(log)
.map(square)
.and_then(sqrt);
// Extract the result.
match result {
Some(x) => println!("Result was {}.", x),
None => println!("This failed.")
}
}
The designers of Go knew when to stop. The designers of Rust don't.
[1] https://web.archive.org/web/20140814230239/http://doc.rust-l...
[2] https://doc.rust-lang.org/std/option/enum.Option.html
'.map' maps over the option. '.and_then' is the monadic bind operation, that you find in pretty much every modern programming language (frequently named 'flatMap'; even Java has this nowadays).
Nor are you forced to use code like the excessively clever version you talk of. People who are used to monadic programming have the choice to.
You're making the same crappy arguments like a broken record. I'm not having the same tired old discussion again.
But this is up to you to enforce.
2) & 3) are pretty much covered in undergrad CS programs. If it hurts, you're doing it wrong - you don't have to dip that deeply in to OO to find excellent patterns for solving it, of you even need to go that far.
On certain platforms like the Win32 API, 2) &3) are hopeless by, it seems, design. Just do your best then :)
Although technically a superset of C, C++ has constructs and paradigms which make you think in totally different ways.
In fact C++ introduces many language features which (should) protect programmers from 'C' mistakes in their C++ code.
For example, in modern C++ you shouldn't manage memory directly, but use smart pointers and containers. You can, but you shouldn't.
And there are dozens of such recommendations. Which is the right approach, imho. You can still do the low-level dangerous stuff if you feel brave, but officially you should stick to the 'safe' paradigms that the language now offers.
However, the paradigms that C enforces on you are the paradigms of how to do things fast. You wear no protection so you are much more nimble, but much more vulnerable at the same time. Which is good for some types of projects, but not for all.
`auto` has very different meanings in both languages, and you can't omit the return type of an int-returning function in C++
Also, C++ doesn't allow implicit casts from void* to any pointer type, which is a common C idiom.
Sure they are. C/C++ are often cobbled together in a sense that they are both low level, non-memory safe and non-type safe languages, as opposite to high level, safe, memory managed (aka "modern") languages.
I recently bought K&R, doing a bit of micro-controller stuff without the Arduino abstractions, and this I can agree with. I now have an idea how code really gets executed on a CPU, and how the contract between the bare metal and the assembler code for doing so looks like.
That the concept of a stack is built into x86, and why calling conventions are important, all of this stuff I had no idea doing Java development for all these years. What do I need a linker for? Object files, what?
I don't really like it, but there is something strangely beautiful about it - if you look hard enough, you can see the machine shining through the unforgiving cold blue ice that is C.
Curious what you mean by that, in what way learning C made you understand this better than Java or any other language did?
#[no_mangle]
pub extern "C" fn count_substrings(value: *const c_char, substr: *const c_char) -> i32
Along the way you inevitably pick up topics like alignment and struct packing.
> It is still one of the most commonly used languages outside of the Bay Area web/mobile startup echo chamber;
Fair.
> C’s influence can be seen in many modern languages;
Saying that that's a reason to learn C is a non sequitur. Why?
> C helps you think like a computer; and,
So does C++. And Rust. And D. All the stuff about databases can be done in any of these languages, C doesn't have a monopoly over letting you be close to the metal. It's one of the only languages that pretty much forces you to be close to the metal, but that's not a plus point.
> Most tools for writing software are written in C (or C++)
True. Hacking on your tools is great. But hacking on your tools rarely requires proficiency in a language (unless you're doing something major, which you're not), I've hacked on tools written in all kinds of languages that I don't know.
And the justification behind this point follows the same flimsy reasoning as the previous one, the reasoning that C is the only low level language out there. The post gives "browsers, operating systems and languages" as examples, but all three of these exist in Rust (Servo, redox/intermezzos/a bunch more, and rustc). I'm sure that D is up to the task for such software too, if it doesn't have them already. C++ of course has all of these.
Sure, you need to know some C when doing low level programming and/or FFI. But nobody's arguing against that. "Everyone “has been meaning to” learn Rust or Go or Clojure over a weekend, not C." is a false dichotomy. With Rust for example it's pretty easy to learn enough C to manage once you've learned Rust (there are tons of folks in the Rust community who have done this). You're not forsaking C, you're just focusing on something better. You can learn enough C to be able to read code and do FFI, and you're pretty much set for writing databases or operating systems or networking stacks or whatever. Reading C isn't too hard and if you speak another low level programming language you can pick this up over a weekend.
The only valid argument I see here is that C is is still used a lot in existing codebases, and you should be proficient if you want to be able to contribute significantly to them. Of course. But cut all the crap about C being the only language that can handle these use cases.
> The post gives "browsers, operating systems and
> languages" as examples
> Saying that that's a reason to learn C is a non sequitur. Why?
To better understand how and why those modern languages work the way they do. The same as learning assembly helps you better understand how computers work (and what C really does under the hood). Learning about layrs under your abstraction layer typically leads to better understanding of your abstraction layer.
I understand the need for mechanical sympathy. This is not mechanical sympathy. At best, this is _historical_ sympathy.
As a programmer, one has no choice most of the time on what language a program should have been written, in my career, I have mostly been modifying and adding code than writing new code from scratch. This mostly means C, for anything close to hardware, as electrical/electronics engineers are familiar with it. Another way of saying this is that, "I program in whatever language, my team is programming in".
Embedded systems also have size limitations and the problem of bootstrapping on new hardware. C has time and again proven to be easy.
If you examine a typical GNU/Linux distro, you see all kinds of programs written in C that ought to have been written in a type safe language because most of the time, C's features were not required for the program.
I wish more and more "new" programs are written in all kinds of languages (not just Rust, but in Python or Haskell or OCaml ..) other than C and that we restrict C to the things we really need it for.
Overall, knowledge of C is only going to help. Whether you want to use it to use it for your next project is something that depends on the problem at hand.
Of course! To be clear, I'm not arguing against learning C in general. I'm very happy that I learned C.
I'm arguing against the point made in the post that you should learn C over newer languages. And like I said, "shit my codebase is in C" (i.e. point #1 from the post) is a totally valid reason to learn C. The other points are not.
The K&R is a classic, but it shows its age, especially as we have reached C11 by now. And C2x might be right around the corner. A third edition of the book won't be that bad.
To clarify, GP here is probably talking about UB security holes, not stuff like XSS. Most intro texts I've seen have "watch out!" notes all over the place.
That's probably a pretty good analogy - it's useful maybe for historical value, but it has to be understood that some of what's listed is no longer best practice and you can't, for instance, go around stoning adulterers and amputating thieves' hands.
So, C is a necessary evil if you want to understand or extend legacy systems whose authors preferred C. It’s also trendy in that people keep it mostly like it is while defending any problems it has. That’s a social thing. Like COBOL and PL/I are with the mainframe apps for companies using them. It’s not the best language for systems programming along a lot of metrics. One doing clean-slate work on a platform can use better languages to do better in the long-term. Short-term benefits matter, though, so such projects often compile to C or include C FFI to benefit from legacy stuff.
LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot.
http://www.catb.org/~esr/faqs/hacker-howto.html
Functional language? Check. Stateless? Check. Reentrant? Check. Has a compiler which can generate machine code ELF binary executables? Check.
That's not to say one shouldn't learn C - after all, C is the contemporary portable assembler. But if one should also learn C, one should learn assembler too, preferably on a processor with an orthogonal instruction set architecture, like a Motorola 68000. Understanding both, we come back to the author's point - without understanding how the machine works, fast, small, efficient and elegant software will remain forever elusive.
The C philosophy "the programmer knows what they're doing" does not necessarily scale. It works when your team is strong or well supervised, but if that is not the case due to location, budget or whatever reason, unless you can afford a static analysis tool like Klocwork that can weed out mistakes while not sacrificing productivity, by going low level you have picked a hard battle.
C gives you a lot of power, but also a lot of rope to hang yourself with. I don't even want to imagine what kind of apocalypse I would see if you give multithreading and memory management powers to the caliber of people I've seen recently.
What many wrongly call the C ABI is actually the OS ABI.
Their OSes didn't had a C ABI, rather an ESPOL, NEWP, Modula, and so forth ABI.
It was the commoditization of UNIX in the industry that pushed C outside UNIX, just like we nowadays have JavaScript outside the browser.
What should make you even more sour is that another opportunity for starting over seems to have been passed up when Google only recently chose to build Fuchsia on top of a C++ based kernel.
Can you please elaborate on it please?
There are some things in C that are not easily exported, like varargs or complex macros, but on the whole the impedance mismatch is a lot less dramatic than in any other language I know, including of course C++.
And as I say, you can do the same in Pascal. We're back where we started. :)
I wonder what if Kernighan, Ritchie et all decided to write UNIX in Pascal, not in C.
Hmmm.... :D
Pascal was designed as a teaching language, then people realized it sucked as a language in the real world, so they extended it. There were quite a few Pascal variants in the late 70s / early 80s, and none of the useful code you could write in them was portable.
C had all the features you needed in an OS-level language, without resorting to variants (the X86 near/far bullshit notwithstanding, you used macros and typedefs to shift that stuff around). So Pascal more or less died in the industry.
I was at Apple when they converted from a Pascal shop to a C shop. There wasn't any big managerial push, just individual engineers or small teams realizing that the nightmare was over and they could use a language that sucked a lot less.
For those of us in MS-DOS and Windows, only Turbo Pascal mattered, to the point it was more relevant to be TP compatible than supporting ISO Extended Pascal, which also sorted out most of the complaints.
Complainants which were nonexistent in Modula-2 anyway.
The industry choose the easy path, now we all pay with our mainstream OSes built on top of a quicksand language.
C is vastly preferable to writing assembler on multiple platforms, though.
The real tragedy is IT Managment(TM), which insisted on C++, and after that inevitably failed (for most things outside of video games), insisted on Java due to all the core dumping craziness.
Can't find the original source doc, but here goes: https://blog.acolyer.org/2016/09/07/the-emperors-old-clothes...
At least K&R took quicksort(), even if they didn't take the array subscript bounds checking part (etc) to heart.
Algol had it right, why screw it up?
I guess it doesn't matter if your (optional) type is word^H^H^H^H int, but this has descended into chaos in Java land.
Since UNIX was written in C, academists/students began to learn C, and that was how the rise of C, now known as "the lingua franca of computing", started.
Personally, one valid reason for me to learn C today is to understand/hack stuffs written in it. A fine example is the Linux kernel.
I still don't get the "C is close to machine" mantra. If you want to understand the machine, why don't just learn assembly instead? :D
They're not hard things to do in assembly, but you'll need to write those every single time you need one. So then you start making macros to handle this for you. By that point the conceptual leap to C isn't very far.
it's almost an ideal hipster language.
Both items have diminished considerably lately, though, and that's something I can appreciate.
I'm surprised (and sorry) to hear that. The Rust community tries very hard to avoid language zealotry. If you see it on any of the Rust forums (can't speak for other sites), please report it.
I've seen lots of well-reasoned complaining about UB and other issues that C/++ are prone to, but not much juvenile hatred.
By now juvenile is something I surely am not.
I feel that both the OP and Dijkstra are right in their own respective way.
I do hope that Rust, for one, will turn out to be part of a path to better practise.
The OO nature of Python can also get in the way of certain things.
As mentioned in the article it is still a good way to learn about computers and it's the true "lingua franca" of our times - that said it needs to be put to rest for infrastructure software now.
I for one welcome our new Rust writing overlords.
Well, guess what? Most of the 'C' code I've written in the last ten years pretty much reflects the selfsame reality - next to nothing is done directly in 'C' but rather as posts of "transactions" to an interface. These may or may not be in text form but it's not much work to make 'em be in text form.
By the way - 'C' is excellent for text manipulation, even using the crufty old library calls.
If you do this and you do it carefully, all the horrors of 'C' become at least manageable. Done carefully enough, you don't even need all the new "safety" furniture.
I blame nobody for not wanting to do this, but can we at least self-identify as "will" or "won't" and behave accordingly? 'C' is no bugbear and your favorite interpreter can't save you from a bugbear that doesn't exist. When problems occur, it's because people didn't take the fifteen minutes or fifteen seconds to prevent them.
I just find myself gobsmacked that people feel so utterly powerless against the language.
I really hate the "C is how a computer really works" argument in favour of learning C.
We still start with the Bohr model in chemistry for the same reasons.
C is trivially easy to learn if you know Assembly Language plus any other imperative language.
My school taught assembly language as a full semester course (along with other low level concepts). That and an intro to computers course that used either Pascal or Fortran were requirements for the 200/300 level courses on operating systems etc. that used C but didn't actually teach it. They made seminars available for those who wanted to be taught C rather than having to learn it themselves. I believe that this is the right approach.
Of course, soon after I went through they fell victim to the hype wagon and switched to Java.
> Most engineers should take head of reason three, although our students also learn computer architecture and at least one assembly language, so have a firm mental model of how computers actually compute.
It is also useful in order to show how those "smart" things in higher level languages work, using standard library as examples.
There is no silver bullet for everything, obviously, but for me the above combination is a match made in heaven. Lua is small and adds only the necessary tools to take care of higher abstrations in many different paradigms.
Even if these two are different languages, they are amazingly complementary. I feel that a good introductory CS course could simply teach in one semester C and the next Lua. By the end of the year students will be able to tackle a huge amount of problems, as well as learned a useful systems and scripting language.
I don't quite see the point of C++ though. Can someone explain me why we should continue to bow into it?
Sure there are things (i.e. virtual classes) which cause an runtime overhead, but even when doing the same thing in C you'd need similar logic to what the C++ compiler produces for you.
If you don't need the C-level sharp knife, then there are a lot of options -- and a lot of reasons to choose them over C or C++.
Personally, I value that C++ is multi-paradigm (I can use classes when they are a good fit, generics when they are a good fit, asm when it's a good fit, etc.), also: trivial interop with C and assembler, no GC, runs directly on the metal. These are reasons to use C++, but not necessarily reasons to "continue to bow into it."
Did I mention generics and metaprogramming? Even if you don't use these directly, their availability makes for flexible and powerful libraries. The STL container library is the obvious example, but modern C++ metaprogramming goes way beyond that.[0]
[0] For example, see Hana: CppCon 2015: https://www.youtube.com/watch?v=cg1wOINjV9U https://github.com/boostorg/hana
Thing is, this exists. It's AWS Lambda. It allows running of arbitrary executables in the sandbox: https://aws.amazon.com/blogs/compute/running-executables-in-...
Is C all that commonly used these days? I rather suspect that it's an unforced error to start a new project in C, and that many wise organisations are replacing buggy C software with slightly-less-buggy software in safer languages.
> C’s influence can be seen in many modern languages
True, but … is this actually that important in a learning situation? Knowing Java will help learning Go (or vice-versa) about as much as learning C would, I think.
> C helps you think like a computer
Like a computer, sure, just not like the computer actually running on one's desk or in a data centre. Modern computers really aren't anything like the C model.
> Most tools for writing software are written in C (or C++)
I suppose that's true, because lots of people have used C, and that really is a good reason to know enough to get around in it, but … maybe one should teach students to use better tools in better languages (Lisp & SmallTalk come to mind).
Seriously, in 2016 it's obvious that C is just wrong.
Is it because it doesn't fit your problem domain? That doesn't mean it's wrong for everything.
Every language has a strong and weak point. Knowing how to use their strong and weak points to elegantly solve any problem is important.
No language is "wrong" or "right"
I think it's obvious, or should be: manual memory management and poor types.
There's no problem domain for which I'd ever want to write C again: not for OSes, not for word processors, not for shell utilities, not for mathematics, not for graphics.
C's strong point is that Unix assumes it.
> No language is "wrong" or "right"
Counterpoints: JavaScript; PHP. Quod erat demonstrandum.
The world of software development is a lot bigger than PCs running high-level operating systems.
I think that Forth would be a far better solution in that situation. C would be a mistake IMHO.
This is arguable.
There are cases where automatic memory management is not a viable option, and other cases where it is a poor choice. Just one example: consider all the trouble people go to with off-heap allocation in Java in order to get reliable low-latency operation.
It most definitely is. Outside of the fact that existing huge projects are written in C (Linux, many compilers/toolchains, databases, etc), it remains the default language for embedded systems. Most smaller embedded device (think Cortex-M class) is running code written in C. This represents an enormous amount of projects spread over dozens of industries and use cases. Someday that may change but right now even C++ has failed to gain traction in these environments.
> Seriously, in 2016 it's obvious that C is just wrong.
This is not true. It all depends on your use case. C is the most well-understood language on the planet - a sort of defacto default. Practices, processes, and tools have been developed over decades to help mitigate problems, often in systems that run for years without SW updates. This can't be discounted.
In certain enterprise applications C are still the best choice. In finance, where I work, C and C++ still reign supreme. Why? There's already a huge multitude of great libraries developed over decades that are mature and battle-tested. Sure, you can write bindings for Rust/Go/D/whatever. But that's a ton of work for minimal benefit.
Fact is, when you get on a plane the avionics software was likely written in C. NASA extensively uses C. The automotive industry extensively uses C. Oh, and a lot of this C is embedded so forget easy software updates.
I think a lot of the hate for C comes from the fact that it lets you do bad things without alerting you. C is a language that mandates solid engineering practices. A good C codebase can be elegant, correct, and fully testable. The language doesn't force this, however. But a nice, well written C library will stand the test of time.
The Bible is useful certainly not just for historical value, but for making you wise for salvation. The Bible is God's master plan for forgiving you, and restoring you to friendship with himself, through Jesus' suffering, death and resurrection explicitly on your behalf. "Believing" in Jesus is not believing whether he exists, or whether God exists. "Believing" in Jesus means not claiming to be without sin, but rather acknowledging your sin, and trusting Jesus' work on the cross alone to save you from it.
I say unfortunately because this gives precedence to the Medina verses, which are marked by cruelty and violence.
This is an odd argument. C has hardly changed or evolved since 1988, so there's not really a need for a new edition.
"Modern C" is a good book on some of the new features.
http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdf