The Descent to C
chiark.greenend.org.uk
chiark.greenend.org.uk
I fully expected him to mention all the land mines of functions that don't check buffer sizes.
But he raised an important example of strcat being O(n).
And I feel like this is a lesson many people could apply to high level languages. For example, I can't count the number of times I've seen people not realize that their language's "remove this element from a vector" method is O(n) and they used it in a loop to get O(n^2). Then when asked about it if their background is high level languages they will have great difficulty reasoning about it, they will pull out BS justifications like I am sure the libraries or the compiler knows what to do here... A good programmer in any language should be able to look at a function signature and have a good intuition about what a reasonable implementation might be, and when to be skeptical about whether or not they would use it.
> To a large extent, the answer is: C is that way because reality is that way. C is a low-level language, which means that the way things are done in C is very similar to the way they're done by the computer itself.
This is probably the one thing I wish the C-haters understood better. Reality has a very anti-GC, pro-pointer bias. These are not arbitrary decisions. Some part of the system needs to work this way. And if we want to continue to have nice things, we need programmers who can competently reason about these layers. I can't imagine that changing anytime soon.
I don't know how many of the "C-haters" actually hate C-the-language because it's too low level, or if they hate the fact that C is used in many cases where a higher level language would be appropriate. It's definitely not reasonable to assert that C is too low level for writing an OS kernel, but when people argue that software like rhythmbox, for example, ought to be written in something a bit higher level, there's some merit. A lot of projects use C just because it's an OK choice that a lot of people are familiar with and few people will have strong objections to.
I'm a long-time programmer that's worked on kernel code, embedded systems, network daemons, etc, but lately I write web applications. There are things about the Javascript community that seem utterly baffling until you realize many (certainly not all!) of the people involved started out as "HTML coders" and don't have the benefit of all that diverse experience.
It means you need to work hard on empathy, and always be both teaching and listening.
> Of course, the comparatively easy string handling in high-level languages will really be having to do all of this same work; it's just that the language hides it from you, and takes care of the tedious details automatically
No, not really. Good string type would reduce the workload down to the hardware. Eg length-prefix strings would avoid the slow strlens for concatenation.
Also imho the horror of undefined behavior should have been underlined even more, eg:
> So C will typically let you just construct any pointer value you like by casting an integer to a pointer type, or by taking an existing pointer to one type and casting it so that it becomes a pointer to an entirely different type.
Afaik both of those are undefined behavior, so it is questionable to say that C "lets" you do that.
But this would be suboptimal in other ways. Besides taking more RAM, it would get in the way of useful tricks like "temporarily shorten string by setting a particular byte in it to \0", or even more useful, "obtain right-terminal substring by simply increasing pointer value".
Different string implementations are more efficient in different scenarios. I love how C gives us standard libraries for a particular string implementation (NULL-terminated) but at the same time allows the flexibility to use whatever implementation we like, by not abstracting all the details out of our control.
>by taking an existing pointer to one type and casting it so that it becomes a pointer to an entirely different type. It isn't that easy, but it's well-defined as long as both pointers are compatible and identically qualified.
I don't understand why people would flag this. It's clearly not spam - do people really think this is not appropriate for hackers?
It has been posted before [0], but I don't consider that to be sufficient justification.
Perhaps it has been flagged because it is appropriate for hackers, the flaggers have not furnished us with any reasoning so it is anyone's guess.
If people are flagging it because it's been posted before, I'd've thought it would be polite for them to point at the previous discussion. Thank you for doing so.
It is sufficient justification (edit: in this case) because the item has had significant attention within about the last year.
HN_FAQ > If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok.
Being a repost is not sufficient justification, as stated above.
EDIT: Cool Dang, I get ya.