8 ms·

I think Zed is right to point these errors out - there are quite a lot of issues with edge case inputs and undeclared assumptions, that people definitely need t

I think Zed is right to point these errors out - there are quite a lot of issues with edge case inputs and undeclared assumptions, that people definitely need to hear about. That said, he appears to be dealing in absolutes too much. If you care about performance (and let's face it, if you're using C you do, otherwise you probably shouldn't be using C) then sometimes you can't handle as much error checking or error correcting as you'd like. In games (where most of my experience is), it's common to have functions that are 'unsafe' by his definition, but that are hidden in compilation units and not exposed in the header, so that the programmer can control exactly where they're called from. If you have a limited number of 'gatekeeper' interface functions that are actually called from outside the module, and these either check/sanitise/assert on their inputs, then the internal private functions can safely assume that they have valid input and just run as quickly and as simply as possibly.

jacquesm 14y ago
There are many other good reasons to use C besides performance. For instance: - cross platform portability - predictability - reliability - long term stability / maintainability - low run-time overhead, fine grained control of memory
- PommeDeTerre 14y ago
  Don't forget the people. Long-time C coders are among the best programmers around. It's hard to understand just how damn good they are until one has gotten a chance to work with one or more of them. The good ones know all levels of the hardware and software stack they're working with. Coupling this knowledge with the raw power of C, they can put together amazing and resource-efficient software in very little time, yet without sacrificing maintainability, security, portability and the other factors you've listed. These are truly the people who make the impossible become possible.
  - bjoe_lewis 14y ago
    if this is true, then I'm going to take C more seriously. I have to move myself forward from TurboC programming.
    - jerf 14y ago
      It is true. How much of the truth is credited to "longtime" and how much is credited to "C" is up for debate, though. Personally I'd put most of it on the "longtime" side, and observe that if you want to learn how to write really efficient, performant code quickly, there are a number of other options developing where you can skip the part where you stab yourself with the language for five years learning where the sharp bits are. C is not dead yet, but I'm feeling increasingly confident we've finally entered the era where its days are now numbered.
      - gillianseed 14y ago
        based upon what? from what I've seen C is doing great, it has it's particular domains which in my opinion are low-level programming and performant, portable code with a small footprint. I can't recall seeing a new language challenging C in the aforementioned areas.
        jerf 14y ago
        Based upon the increasing number of languages showing up that combine high performance with higher levels of abstraction than C, and the increasing number of serious languages gunning for C specifically, like Rust. C has ridden for a long time on the fact that we didn't know how to combine high performance and systems functionality with high abstraction languages, so you had your choice of C or C-like and fast, or high abstraction and slow, like Python or Perl or Ruby. This gap is closing, fairly quickly now, and once it does C will start experiencing a rapid decline into a niche language, rather than the lingua franca of computing. It has advantages that have kept it going for a long time, but it has terrible disadvantages too, and once the two are separable, people are going to want to so separate. Already a great deal of what was once automatically C or C++ has gone to some sort of bytecode (Java or .Net), even on things you would used to simply automatically assume to be "embedded", like your cell phone. The decline has already started. Of course it won't die. Computer languages never really die. You can still get a job doing COBOL, and in fact get paid quite well. But 10 years from now, I think on the systems considered "modern" at the time, it will not be the "default" language anymore.
- slurry 14y ago
  Not to mention: - lightweight ABI, accessible from just about any other language on the planet. - huge existing base of liberally-licensed code available for re-use - basically the only language that is not a) legacy-stamped or b) bloated beyond learnability after more than two decades of use (or, in C's case, twice that.) I seldom use C myself, but its strong points are undersold by the "garbage collection is to slooooow" kiddies.
enry_straker 14y ago
Though it might come across as 'dealing in absolutes,' Zed is making the broader point that when one starts learning programming, it's not good to put any book on a pedestal and blindly follow their style - without working through the code. It's similar to literature where people tend to ascribe the word 'classic' and yet rarely bother to read, understand or appreciate them. Your example of unsafe functions might work for you but might not be the best example in a book which is being revered as "the classic book on C" and which influenced almost every major language and book thereafter.
- NickPollard 14y ago
  I agree - that's why I started by saying that Zed is right to point them out, as I realise that he is teaching people new to C (and potentially to programming). I added my caveats just to point out to the slightly more experienced programmers here that it's not quite the whole story.
- zwischenzug 14y ago
  As an interesting analogy, some great thinkers have heavily criticised Shakespeare for some terrible imagery - notably Wittgenstein and Tolstoy. http://bloggingshakespeare.com/do-we-really-like-shakespeare http://bloggingshakespeare.com/do-we-really-like-shakespeare
sea6ear 14y ago
I'm basically replying to this comment so I can find it again. I think your point about unsafe functions being fine as long as access to them is only possible through controlled access points that verify sane input is one of the most interesting points I've seen in a while.
- angersock 14y ago
  This is exactly my experience working with engine code--there are some very clean, fast, precise, and horrifically unsafe functions in our rendering system and other places that are acceptable because we can make guarantees about what data gets there from elsewhere. The mental image is an access panel, behind which lay hundreds of whirling razor-sharp gears--presumably if you open it you know what you're doing and are careful. This is what people pushing for abstraction are about, and why they're correct in some cases.

jacquesm 14y ago

There are many other good reasons to use C besides performance. For instance: - cross platform portability - predictability - reliability - long term stability / maintainability - low run-time overhead, fine grained control of memory

PommeDeTerre 14y ago
Don't forget the people. Long-time C coders are among the best programmers around. It's hard to understand just how damn good they are until one has gotten a chance to work with one or more of them. The good ones know all levels of the hardware and software stack they're working with. Coupling this knowledge with the raw power of C, they can put together amazing and resource-efficient software in very little time, yet without sacrificing maintainability, security, portability and the other factors you've listed. These are truly the people who make the impossible become possible.
- bjoe_lewis 14y ago
  if this is true, then I'm going to take C more seriously. I have to move myself forward from TurboC programming.
  - jerf 14y ago
    It is true. How much of the truth is credited to "longtime" and how much is credited to "C" is up for debate, though. Personally I'd put most of it on the "longtime" side, and observe that if you want to learn how to write really efficient, performant code quickly, there are a number of other options developing where you can skip the part where you stab yourself with the language for five years learning where the sharp bits are. C is not dead yet, but I'm feeling increasingly confident we've finally entered the era where its days are now numbered.
    - gillianseed 14y ago
      based upon what? from what I've seen C is doing great, it has it's particular domains which in my opinion are low-level programming and performant, portable code with a small footprint. I can't recall seeing a new language challenging C in the aforementioned areas.
      - jerf 14y ago
        Based upon the increasing number of languages showing up that combine high performance with higher levels of abstraction than C, and the increasing number of serious languages gunning for C specifically, like Rust. C has ridden for a long time on the fact that we didn't know how to combine high performance and systems functionality with high abstraction languages, so you had your choice of C or C-like and fast, or high abstraction and slow, like Python or Perl or Ruby. This gap is closing, fairly quickly now, and once it does C will start experiencing a rapid decline into a niche language, rather than the lingua franca of computing. It has advantages that have kept it going for a long time, but it has terrible disadvantages too, and once the two are separable, people are going to want to so separate. Already a great deal of what was once automatically C or C++ has gone to some sort of bytecode (Java or .Net), even on things you would used to simply automatically assume to be "embedded", like your cell phone. The decline has already started. Of course it won't die. Computer languages never really die. You can still get a job doing COBOL, and in fact get paid quite well. But 10 years from now, I think on the systems considered "modern" at the time, it will not be the "default" language anymore.
slurry 14y ago
Not to mention: - lightweight ABI, accessible from just about any other language on the planet. - huge existing base of liberally-licensed code available for re-use - basically the only language that is not a) legacy-stamped or b) bloated beyond learnability after more than two decades of use (or, in C's case, twice that.) I seldom use C myself, but its strong points are undersold by the "garbage collection is to slooooow" kiddies.

enry_straker 14y ago

Though it might come across as 'dealing in absolutes,' Zed is making the broader point that when one starts learning programming, it's not good to put any book on a pedestal and blindly follow their style - without working through the code. It's similar to literature where people tend to ascribe the word 'classic' and yet rarely bother to read, understand or appreciate them. Your example of unsafe functions might work for you but might not be the best example in a book which is being revered as "the classic book on C" and which influenced almost every major language and book thereafter.

NickPollard 14y ago
I agree - that's why I started by saying that Zed is right to point them out, as I realise that he is teaching people new to C (and potentially to programming). I added my caveats just to point out to the slightly more experienced programmers here that it's not quite the whole story.
zwischenzug 14y ago
As an interesting analogy, some great thinkers have heavily criticised Shakespeare for some terrible imagery - notably Wittgenstein and Tolstoy. http://bloggingshakespeare.com/do-we-really-like-shakespeare http://bloggingshakespeare.com/do-we-really-like-shakespeare

sea6ear 14y ago

I'm basically replying to this comment so I can find it again. I think your point about unsafe functions being fine as long as access to them is only possible through controlled access points that verify sane input is one of the most interesting points I've seen in a while.

angersock 14y ago
This is exactly my experience working with engine code--there are some very clean, fast, precise, and horrifically unsafe functions in our rendering system and other places that are acceptable because we can make guarantees about what data gets there from elsewhere. The mental image is an access panel, behind which lay hundreds of whirling razor-sharp gears--presumably if you open it you know what you're doing and are careful. This is what people pushing for abstraction are about, and why they're correct in some cases.