7 ms·

I've always like the description of C as just being "raw memory, but with syntactic sugar." I think C is still so pervasive for 2 simple reasons (I might be wr

I've always like the description of C as just being "raw memory, but with syntactic sugar." I think C is still so pervasive for 2 simple reasons (I might be wrong): 1) It's a small language. Compared to many newer languages (Swift, modern C++, old C++, Objective-C, Java), it's quite tiny. The language itself can be learned in short time. (Which is deceptive, because properly using what you have learned takes longer than a short time). 2) It's fast. It's just direct memory access, direct and explicit hardware manipulation. And whether justified or not, there is a very large portion of the developer community that remains obsessed with speed. I see it all the time, even when speed isn't not going to matter enough to justify C. I often see people going way out of their way, making their work much more time-consuming, because of their everlasting pursuit of writing the fastest damn program they possibly can.

danieltillett 9y ago
The thing I love about C is it almost always does what you want fast, but you are never certain. No matter how much you think you know C, there is always some new edge case to experience. C is exciting.
- akvadrako 9y ago
  I completely disagree with this. C is the only language I ever used I felt I had mastered. Sometimes I needed to check things in the spec or pause to consider the C99/C89 discrepancies, but essentially I knew everything about it after just a few years of daily use. I've never felt that way with Python, JS, Ruby, Java, C++ or any of the other languages I've used. They are at least 10X more complex in terms of primitives and non-trivial interactions.
  - barrkel 9y ago
    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.
    - akvadrako 9y ago
      Maybe many people do have incorrect assumptions about C, but I wouldn't say it's deceptive. The abstract nature becomes plain when using an optimising compiler for a while. And they have been the norm for at least 20 years.
      - mrec 9y ago
        Optimizing compilers have been around for yonks, sure, but I think taking aggressive advantage of UB is relatively recent. See e.g. Regehr in 2012 [1] : > The current crop of C and C++ compilers will exploit undefined behaviors to generate efficient code [...], but not consistently or well. It’s time for us to take this seriously. [1] https://blog.regehr.org/archives/761 https://blog.regehr.org/archives/761
        akvadrako 9y ago
        I see your comment is grey, so I guess people down-voted you and maybe you want to know why. It's because you are wrong. Compiler optimisations have always been relevant; even in the 90's they would omit entire blocks of code or reorder operations for example. I assume now it's more aggressive, because undefined behavior should never be relied upon. That's the point.
        mrec 9y ago
        I think you're reading me as saying something much stronger than what I actually meant. When we talk about C being "deceptive" we don't need to consider optimizations that respect the as-if rule. (Well, maybe when looking at the C->asm mapping or trying to benchmark, but that's not the level most people are working at.) The trend toward UB-based optimizations seems significant to me because they can and will take a bunch of C code which looks superficially reasonable, and which used to do X as intended, and suddenly (and perfectly legally) make it start doing Y instead. I assumed that's what barrkel was alluding to above. And yes, I'm sure there are old optimizations which will also do that, but basic things like hoisting and reordering and unrolling and dead-code elimination don't fall into that category.
  - kahlonel 9y ago
    Lookup "Dunning-Kruger effect"
  - danieltillett 9y ago
    That is where the excitement comes from. You think you know C, but when you least expect it something come up that bites you in the backside. I love C for its warts and all, but you should treat it like a tamed wild animal.
- empath75 9y ago
  And always new buffer-overflows to find.
  - Analemma_ 9y ago
    I know, right? The GP’s point baffles me. C is a tool. I don’t want my tools to be exciting! I want my movies and vacations and relationships to be exciting, but not my tools. I want my tools to be boring and predictable.
  - megous 9y ago
    I don't find it a common bug in day to day programming. It may be well known because of the security implications. I get perhaps a 2-3 crashes a year from buffer overflow when developing an app. OTOH, I'm constantly being pumelled by failed type checks, undefined variables, uninitialized variables, etc. Last time compiler even warned me about buffer overflow, which was nice.
- reza_n 9y ago
  Do you have any examples of this uncertainty? I hear this argument a lot, but have a hard time understanding why this seems to be a common grievance. I've been writing C for years and never once did I hit a scenario of dealing with undefined or uncertain behavior. Writing normal C is very well defined. No?
  - pacaro 9y ago
    I find this hard to believe. Even initialized variables are undefined behavior, I’ve yet to meet a c programmer that hasn’t been bitten by this.
    - reza_n 9y ago
      Please explain how that is UB?
      - pacaro 9y ago
        Ugh. Sorry autocorrect, should read “uninitialized variables”
        reza_n 9y ago
        It is well understood that all variables need to be initialized. Most compilers consider uninitialized variables an error. So I would say someone running into this and possibly other UB scenarios is just a case of writing bad code.
- dxhdr 9y ago
  C is very unexciting to me, in a good way. With C you can figure out what the compiler has done by inspecting the generated code. Have fun doing that with an interpreted language, or compiled output from any other language for that matter! Actually there are a few other languages that are great for debugging runtime code behavior; Lua comes to mind.
jjrh 9y ago
> I often see people going way out of their way, making their work much more time-consuming, because of their everlasting pursuit of writing the fastest damn program they possibly can. Problem is you have the complete opposite on the other side, folks who don't even think about speed (usually because their development machine is quite powerful and so they don't notice). Thus we end up with programs that are resource hogs and slow that have no good reason to be. There is a middle ground to be found I think.
- deleted 9y ago
  [deleted]
- hellofunk 9y ago
  Some programs are resource hogs. Most programs don't justify the effort to be pre-occupied with speed. I think it's fine for a developer to place runtime speed low on their priorities until they see an actual problem. Then, if it's hogging resources for something, they can do something about it. Thing is, however, for most tasks, this will not be necessary, and for many programs it will not be a problem, even if you use the slowest algorithms.
kazinator 9y ago
The C90 standard was 230 pages, but C11 is up to around 683 now: some 3X bigger. That's just to describe a language whose computational model consists of Von Neumann style word mangling, and which has next to no useful library functions. (You want a simple linked list, you have to write code or go third party.) You can treat C as a small language, if you don't have to work with anyone else.
- CalChris 9y ago
  Yes 683 pages, but 178 of that is the language: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf That's up from 95 in C90, a factor of 2 not 3 in 20 years. http://read.pudn.com/downloads133/doc/565041/ANSI_ISO%2B9899-1990%2B[1].pdf http://read.pudn.com/downloads133/doc/565041/ANSI_ISO%2B9899... You can treat Rust as a useful language as long as you don't need to get work done. I rather like C11. I would have liked Rust, I tried, if they'd have known when to say no or if they valued sparseness for its readability because it reads like C+++: const USAGE: &'static str = "usage: blah blah"; By contrast, I like what seL4 did with C. They wrote in C and proved in Isabelle.
  - steveklabnik 9y ago
    In today's Rust you can drop the 'static.
    - deathanatos 9y ago
      This example is one of those things I keep running into though, and don't fully understand: why does type inference not work on consts? e.g., here, why can't we drop the entire type: const USAGE = "usage: blah blah"; The RHS has sufficient type information, does it not? After all, if this were a let USAGE = ... inside a function, that would be sufficient. (I don't find this particular bit a deal-breaker though; thus far, I quite like Rust.)
      - steveklabnik 9y ago
dingo_bat 9y ago
3) Compilation is much faster than C++.
- hellofunk 9y ago
  There's a tradeoff, however. You can trade C++'s compilation time for the program's runtime, in many cases. You can now do quite a lot at compile time in C++ that is not possible in C. Therefore, technically, C++ has slower compilation time but potential for faster runtime.
kakwa_ 9y ago
> 2) It's fast. It's just direct memory access, direct and explicit hardware manipulation I also find C really handy for parsing binary formats (ASN1, Ms EMF...), parsing binary stuff in Python for example feels miserable. However, for manipulation string based formats (xml, json, yaml), C is quite miserable, even with the help of libs like libjson-c or libxml2. And to be fair, even for parsing binary formats, C can be quite unforgiving. I still have some traumatic souvenirs from the first time I ran American Fuzzy Lop on my EMF to SVG converter... (by the way, I love the afl logo: https://upload.wikimedia.org/wikipedia/commons/f/fa/AFL_Fuzz_Logo.gif https://upload.wikimedia.org/wikipedia/commons/f/fa/AFL_Fuzz...)
- sametmax 9y ago
  In python you just import pyasn...
  - makapuf 9y ago
    well, currently writing binary tools using python and I find that quite pleasing with the struct module ..
- nurettin 9y ago
  Parsing binary with ruby: https://github.com/nurettin/hst/blob/master/lib/hst.rb https://github.com/nurettin/hst/blob/master/lib/hst.rb

danieltillett 9y ago

The thing I love about C is it almost always does what you want fast, but you are never certain. No matter how much you think you know C, there is always some new edge case to experience. C is exciting.

akvadrako 9y ago
I completely disagree with this. C is the only language I ever used I felt I had mastered. Sometimes I needed to check things in the spec or pause to consider the C99/C89 discrepancies, but essentially I knew everything about it after just a few years of daily use. I've never felt that way with Python, JS, Ruby, Java, C++ or any of the other languages I've used. They are at least 10X more complex in terms of primitives and non-trivial interactions.
- barrkel 9y ago
  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.
  - akvadrako 9y ago
    Maybe many people do have incorrect assumptions about C, but I wouldn't say it's deceptive. The abstract nature becomes plain when using an optimising compiler for a while. And they have been the norm for at least 20 years.
    - mrec 9y ago
      Optimizing compilers have been around for yonks, sure, but I think taking aggressive advantage of UB is relatively recent. See e.g. Regehr in 2012 [1] : > The current crop of C and C++ compilers will exploit undefined behaviors to generate efficient code [...], but not consistently or well. It’s time for us to take this seriously. [1] https://blog.regehr.org/archives/761 https://blog.regehr.org/archives/761
      - akvadrako 9y ago
        I see your comment is grey, so I guess people down-voted you and maybe you want to know why. It's because you are wrong. Compiler optimisations have always been relevant; even in the 90's they would omit entire blocks of code or reorder operations for example. I assume now it's more aggressive, because undefined behavior should never be relied upon. That's the point.
        mrec 9y ago
        I think you're reading me as saying something much stronger than what I actually meant. When we talk about C being "deceptive" we don't need to consider optimizations that respect the as-if rule. (Well, maybe when looking at the C->asm mapping or trying to benchmark, but that's not the level most people are working at.) The trend toward UB-based optimizations seems significant to me because they can and will take a bunch of C code which looks superficially reasonable, and which used to do X as intended, and suddenly (and perfectly legally) make it start doing Y instead. I assumed that's what barrkel was alluding to above. And yes, I'm sure there are old optimizations which will also do that, but basic things like hoisting and reordering and unrolling and dead-code elimination don't fall into that category.
- kahlonel 9y ago
  Lookup "Dunning-Kruger effect"
- danieltillett 9y ago
  That is where the excitement comes from. You think you know C, but when you least expect it something come up that bites you in the backside. I love C for its warts and all, but you should treat it like a tamed wild animal.
empath75 9y ago
And always new buffer-overflows to find.
- Analemma_ 9y ago
  I know, right? The GP’s point baffles me. C is a tool. I don’t want my tools to be exciting! I want my movies and vacations and relationships to be exciting, but not my tools. I want my tools to be boring and predictable.
- megous 9y ago
  I don't find it a common bug in day to day programming. It may be well known because of the security implications. I get perhaps a 2-3 crashes a year from buffer overflow when developing an app. OTOH, I'm constantly being pumelled by failed type checks, undefined variables, uninitialized variables, etc. Last time compiler even warned me about buffer overflow, which was nice.
reza_n 9y ago
Do you have any examples of this uncertainty? I hear this argument a lot, but have a hard time understanding why this seems to be a common grievance. I've been writing C for years and never once did I hit a scenario of dealing with undefined or uncertain behavior. Writing normal C is very well defined. No?
- pacaro 9y ago
  I find this hard to believe. Even initialized variables are undefined behavior, I’ve yet to meet a c programmer that hasn’t been bitten by this.
  - reza_n 9y ago
    Please explain how that is UB?
    - pacaro 9y ago
      Ugh. Sorry autocorrect, should read “uninitialized variables”
      - reza_n 9y ago
        It is well understood that all variables need to be initialized. Most compilers consider uninitialized variables an error. So I would say someone running into this and possibly other UB scenarios is just a case of writing bad code.
dxhdr 9y ago
C is very unexciting to me, in a good way. With C you can figure out what the compiler has done by inspecting the generated code. Have fun doing that with an interpreted language, or compiled output from any other language for that matter! Actually there are a few other languages that are great for debugging runtime code behavior; Lua comes to mind.

jjrh 9y ago

> I often see people going way out of their way, making their work much more time-consuming, because of their everlasting pursuit of writing the fastest damn program they possibly can. Problem is you have the complete opposite on the other side, folks who don't even think about speed (usually because their development machine is quite powerful and so they don't notice). Thus we end up with programs that are resource hogs and slow that have no good reason to be. There is a middle ground to be found I think.

deleted 9y ago
[deleted]
hellofunk 9y ago
Some programs are resource hogs. Most programs don't justify the effort to be pre-occupied with speed. I think it's fine for a developer to place runtime speed low on their priorities until they see an actual problem. Then, if it's hogging resources for something, they can do something about it. Thing is, however, for most tasks, this will not be necessary, and for many programs it will not be a problem, even if you use the slowest algorithms.

kazinator 9y ago

The C90 standard was 230 pages, but C11 is up to around 683 now: some 3X bigger. That's just to describe a language whose computational model consists of Von Neumann style word mangling, and which has next to no useful library functions. (You want a simple linked list, you have to write code or go third party.) You can treat C as a small language, if you don't have to work with anyone else.

CalChris 9y ago
Yes 683 pages, but 178 of that is the language: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf That's up from 95 in C90, a factor of 2 not 3 in 20 years. http://read.pudn.com/downloads133/doc/565041/ANSI_ISO%2B9899-1990%2B[1].pdf http://read.pudn.com/downloads133/doc/565041/ANSI_ISO%2B9899... You can treat Rust as a useful language as long as you don't need to get work done. I rather like C11. I would have liked Rust, I tried, if they'd have known when to say no or if they valued sparseness for its readability because it reads like C+++: const USAGE: &'static str = "usage: blah blah"; By contrast, I like what seL4 did with C. They wrote in C and proved in Isabelle.
- steveklabnik 9y ago
  In today's Rust you can drop the 'static.
  - deathanatos 9y ago
    This example is one of those things I keep running into though, and don't fully understand: why does type inference not work on consts? e.g., here, why can't we drop the entire type: const USAGE = "usage: blah blah"; The RHS has sufficient type information, does it not? After all, if this were a let USAGE = ... inside a function, that would be sufficient. (I don't find this particular bit a deal-breaker though; thus far, I quite like Rust.)
    - steveklabnik 9y ago

dingo_bat 9y ago

3) Compilation is much faster than C++.

hellofunk 9y ago
There's a tradeoff, however. You can trade C++'s compilation time for the program's runtime, in many cases. You can now do quite a lot at compile time in C++ that is not possible in C. Therefore, technically, C++ has slower compilation time but potential for faster runtime.

kakwa_ 9y ago

> 2) It's fast. It's just direct memory access, direct and explicit hardware manipulation I also find C really handy for parsing binary formats (ASN1, Ms EMF...), parsing binary stuff in Python for example feels miserable. However, for manipulation string based formats (xml, json, yaml), C is quite miserable, even with the help of libs like libjson-c or libxml2. And to be fair, even for parsing binary formats, C can be quite unforgiving. I still have some traumatic souvenirs from the first time I ran American Fuzzy Lop on my EMF to SVG converter... (by the way, I love the afl logo: https://upload.wikimedia.org/wikipedia/commons/f/fa/AFL_Fuzz_Logo.gif https://upload.wikimedia.org/wikipedia/commons/f/fa/AFL_Fuzz...)

sametmax 9y ago
In python you just import pyasn...
- makapuf 9y ago
  well, currently writing binary tools using python and I find that quite pleasing with the struct module ..
nurettin 9y ago
Parsing binary with ruby: https://github.com/nurettin/hst/blob/master/lib/hst.rb https://github.com/nurettin/hst/blob/master/lib/hst.rb