4 ms·

> If you're willing to switch to "friendly C", why wouldn't you already be switching to Rust, or even Haskell? Because you are already using it. You, the media

> If you're willing to switch to "friendly C", why wouldn't you already be switching to Rust, or even Haskell? Because you are already using it. You, the median C developer, are already writing code assuming that it will be compiled by a friendly C compiler. Friendly C is one of the most widely used programming languages on the planet as of 2015. The most widely used SSL/TLS stacks are written in friendly C. The “friendly C” manifesto is not intended for C developers, an amazing proportion of whom already write friendly C. The manifesto is aimed at C compiler developers. Friendly C just needs a compiler, or perhaps several of them.

to3m 12y ago
Yes. To quote one of the links I posted: "The tl;dr version of this is that the C compiler writers have no idea who their users are, so they keep fucking up working code [...] All of this only hurts the systems-level programmer (and I claim is of dubious value to the high-level guys). Which is why I insist that the compiler writers don't know their own customers. C is a systems-programming language! Why do you want to screw the systems-programmer to help the high-level programmer, when the high-level guy has long since moved to C++ and is bumbling around with STL?" That whole post is worth reading. Though something of a tossed-off ranty blog post, I think it very accurate.
- lmm 12y ago
  The only kind of systems-programmer who should be writing C is the kind who is capable of manual memory management. The "optimized DSP kernel loops" usually only possible to write with unsigned arithmetic anyway. And if you're using unions at all it's because you're in a super-performance-critical place, in which case the strict-aliasing rules absolutely are valuable (and "other parts of your generated code are slower than MSVC" is a stupid argument). The problem isn't with C, it's with people using C where it's the wrong tool.
- pascal_cuoq 12y ago
  > Though something of a tossed-off ranty blog post Touché.
  - to3m 12y ago
    Think of it not as a criticism, nor a suggestion that there is anything wrong with its author writing it that way. It's simply an admittance in advance that this thing I'm recommending might come across, on first reading, as more easily dismissed than I think it should be. Perhaps I phrased it poorly, though. My first go sounded wishy-washy, so I rejigged it... I could well have over-tightened things.

to3m 12y ago

Yes. To quote one of the links I posted: "The tl;dr version of this is that the C compiler writers have no idea who their users are, so they keep fucking up working code [...] All of this only hurts the systems-level programmer (and I claim is of dubious value to the high-level guys). Which is why I insist that the compiler writers don't know their own customers. C is a systems-programming language! Why do you want to screw the systems-programmer to help the high-level programmer, when the high-level guy has long since moved to C++ and is bumbling around with STL?" That whole post is worth reading. Though something of a tossed-off ranty blog post, I think it very accurate.

lmm 12y ago
The only kind of systems-programmer who should be writing C is the kind who is capable of manual memory management. The "optimized DSP kernel loops" usually only possible to write with unsigned arithmetic anyway. And if you're using unions at all it's because you're in a super-performance-critical place, in which case the strict-aliasing rules absolutely are valuable (and "other parts of your generated code are slower than MSVC" is a stupid argument). The problem isn't with C, it's with people using C where it's the wrong tool.
pascal_cuoq 12y ago
> Though something of a tossed-off ranty blog post Touché.
- to3m 12y ago
  Think of it not as a criticism, nor a suggestion that there is anything wrong with its author writing it that way. It's simply an admittance in advance that this thing I'm recommending might come across, on first reading, as more easily dismissed than I think it should be. Perhaps I phrased it poorly, though. My first go sounded wishy-washy, so I rejigged it... I could well have over-tightened things.