Hacker News Reader

Comment by hellofunk | Hacker News Reader

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.

View on HN

> 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.

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.

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.

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.

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.

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.

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

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.

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.

> And yes, I'm sure there are old optimizations which will also do that

So then it's not new behavior.

I think the pre- versus post-increment is a great example of this -- Assembly language is unambiguous about when the increment happens. It happens when you hit the increment instruction. The situation in C is almost intentionally confusing. This was done back in the early days of structured programming. I suspect the motivation was to win people over from using gotos for everything, since it allows for variation in how loops and conditionals are executed.

Some of the processors back then had various pre-increment vs post-decrement addressing modes so there was a performance difference which one you used. To keeps things unambiguous, use the increment operator in a statement by itself.

Interesting, that sheds some light on the situation!

And indeed, I do always use the increment operator by itself. The amount of extra thought it takes to distinguish

    while(i--)

from

    while(--i)

just isn't worth it, when instead I could write

    for(;i>0;i--)

which is very clear about what the last value of i in the loop is.

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.

And always new buffer-overflows to find.

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.

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.

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?

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.

Please explain how that is UB?

Ugh. Sorry autocorrect, should read “uninitialized variables”

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.

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.

> 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...)

In python you just import pyasn...

well, currently writing binary tools using python and I find that quite pleasing with the struct module ..

Parsing binary with ruby: https://github.com/nurettin/hst/blob/master/lib/hst.rb

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.

Yes 683 pages, but 178 of that is the language:

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...

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.

In today's Rust you can drop the 'static.

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.)

This was an explicit decision; we could do this kind of inference but chose not to, similar to how you must declare the types of functions. We started with the most conservative choice, and then are feeling it out; that's why you can now drop the lifetime.

Not sure why this is being downvoted. The GP commenter is mistaken, the following line is completely valid Rust:

    const USAGE: &str = "usage: blah blah";

Compare it to the equivalent in C:

    const char *USAGE = "usage: blah blah";

And while you are at it, compare that to:

  #define USAGE "usage: blah blah"

The equivalent C needs a second const -- your first one refers to the data behind the string but not the string pointer, and is more like Rust's `let usage: &str`.

    const char * const USAGE = "usage: blah blah";

Or rather `let mut usage: &str`. Rust actually is kind of similar to C here in that the pointer and pointee can be separately const or mutable. But in Rust "const" is the default and mut needing to be explicitly declared, whereas with C it's the other way around.

In C90, the Language clause goes from page 18 to 95, so 78 pages. Not 3X less but 2.3X.

> The C90 standard was 230 pages, but C11 is up to around 683 now: some 3X bigger.

The C11 standard (ISO/IEC 9899:2011) adds support for threading and atomics, and adds IEC 60559 specifications in its annex.

Yet, the language specification part of ISO/IEC 9899:2011 is less than 180 pages, and the remaining pages are dedicated to libraries and the annex, which on itself takes over 200 pages.

This if a far cry of Java's full formal language definition

> next to no useful library functions

Ah, compared with its early 1980s competition (Pascal, Modula-2, BASIC), C was quite lavishly equipped with library functions.

Now, get off my lawn, kids!

3) Compilation is much faster than C++.

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.

Reply on news.ycombinator.com