Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A critique of "How to C in 2016"

github.com

Post reply on HN
Print view View original

111–120 of 181 posts

Re: A critique of "How to C in 2016"

#111

Post by benbenolson »

pjmlp wrote: post #79
dietrichepp wrote: post #47

Earlier quoted context omitted.

But that's the most important thing, isn't it? Being able to compile and run your code? I mean, the English language sure isn't popular for its intrinsic merits either, but here we are.

Sure, but in a way C is the JavaScript of systems programming languages, in a deep need of a "The Good Parts" book as well.

I'm sorry, but is this comment a joke? Have you ever read "The C Programming Language", and seen how simple C is? These arguments that the two OPs are having are important, but only when faced with obscure architectures that nearly nothing but C will run on.

Conversely, JavaScript's failures are not because of the wide variety of architectures that it supports (a tiny fraction of C's), but instead on the monolithic and bad design of the language. If you read "The C Programming Language", you'll realize that in the ~240 pages of text, you know basically every feature of the language. It's small, and it's elegant, and it's portable. JavaScript is none of those.

Re: A critique of "How to C in 2016"

#112

Post by jevgeni »

pjmlp wrote: post #79
dietrichepp wrote: post #47

Earlier quoted context omitted.

But that's the most important thing, isn't it? Being able to compile and run your code? I mean, the English language sure isn't popular for its intrinsic merits either, but here we are.

Sure, but in a way C is the JavaScript of systems programming languages, in a deep need of a "The Good Parts" book as well.

There are tons of such books.

Re: A critique of "How to C in 2016"

#113

Post by kbart »

oldmanjay wrote: post #107
kbart wrote: post #101

Earlier quoted context omitted.

"Why on Earth would you voluntarily code in a language where people can debate something as simple as which type to use for integers, unless you absolutely had to?" Because we have no alternatives so far. I do C programming for a living, but I'd be more than happy if there were some type and memory safe language I could use to program any tiny, obscure MCU, that could stay at least in the same order of magnitude of s…

You're aware that "we have no choice" does not answer a question about why you would do something voluntarily, right?

I just confirm, that majority of C programmers nowadays do that because of "they absolutely had to".

Re: A critique of "How to C in 2016"

#115

Post by benbenolson »

appleflaxen wrote: post #96

> The first rule of C is don't write C if you can avoid it. My C skills are non-existent, but it occurs to me while reading the response that when two people who have so carefully considered the subject can arrive at such different places... then yes, you probably shouldn't write C if you can avoid it.

C is the only language that will run on certain strange systems, and that is the only reason that most of these quibbles even matter. It's more of an argument of "What is the most portable way to write C?"

C is a very small and elegant language that never lies to you. There aren't any useless functions that are specific to one use case, and things that you don't really, really need are simply left out of the language. This means that instead of spending hours learning the language and all of its quirks, you get to focus on the problem that you're trying to solve, and come up with the most efficient solution possible (there's a reason why almost all performance tests use C as 1). You don't have any language quirks like those that are discussed in this article, unless you are running an architecture that has similar quirks, in which case you're going to have quirks no matter what you do. Edge use cases, as with everything, may cause a bit of quirkiness.

That being said, don't be scared off from C just because of these pedantic arguments.

Re: A critique of "How to C in 2016"

#116

Post by oldmanjay »

Reading this as someone who neither loves not loathes C, I would not have written this as a series of rebuttals. It makes the essay seem defensive and nit picky. I get more of a sense of emotional attachment to a particular way than any sort of reasoning.

Re: A critique of "How to C in 2016"

#117

Post by benbenolson »

grabcocque wrote: post #8

This, ladies and gentlemen, is why C gives me the willies. And why this happens: http://www.cvedetails.com/vulnerability-list/year-2016/month...

Those are due to programmer error. The fact that C doesn't lie to you means that it takes a bit more experience to program properly; as with all things, with great power comes great responsibility. You don't blame the gun for killing people, you blame the person for shooting it.

Re: A critique of "How to C in 2016"

#118

Post by whyever »

ue_ wrote: post #14
legulere wrote: post #9

I disagree with many of the arguments. Many of them are ignoring the reality of today. One example: > If you want bytes, use unsigned char. If you want octets, use uint8_t Bytes and octets are the same today. I never came across a system where this wasn't true. I was never told about a system where this wasn't true. I wasn't even told that there once were systems where this wasn't true until fairly recently.

>Bytes and octets are the same today. I never came across a system where this wasn't true. The fact that all modern systems use eight bit bytes is no reason to assume that a byte is eight bits. The fact is that a byte is not eight bits large. People may wish to run code on "historical" systems, and someone may wish to create a 9-bit byte system for fun. To write C code with an assumption that things are one way, when…

I would be very surprised if some non-trivial C code written for x86 compiles and runs unmodified on exotic platforms. Besides, I don't want to be hold back by people wishing to run code on historical or experimental systems.

Re: A critique of "How to C in 2016"

#119

Post by appleflaxen »

benbenolson wrote: post #115
appleflaxen wrote: post #96

> The first rule of C is don't write C if you can avoid it. My C skills are non-existent, but it occurs to me while reading the response that when two people who have so carefully considered the subject can arrive at such different places... then yes, you probably shouldn't write C if you can avoid it.

C is the only language that will run on certain strange systems, and that is the only reason that most of these quibbles even matter. It's more of an argument of "What is the most portable way to write C?" C is a very small and elegant language that never lies to you. There aren't any useless functions that are specific to one use case, and things that you don't really, really need are simply left out of the language…

That's a great point; thanks for the context.

Re: A critique of "How to C in 2016"

#120

Post by whyever »

krylon wrote: post #98
EliRivers wrote: post #21

Earlier quoted context omitted.

Because it's simple and low-overhead and compilers for it exist on every lump of hardware I've ever had to work with, from a clunky x64 to a PIC to a TigerSHARC to a bizarre DSP thingy from a tiny fab lab somewhere. A great many of the problems that people experience with C code can actually be nullified (zing!) by finding a competent C programmer who does the job properly. A tool being easy to misuse doesn't mean we…

The key phrase here is " if you can avoid it". When your target platform is an 8-bit microcontroller or an embedded system with hard real-time requirements, your options are very limited. But there are plenty of situations where there are alternatives, and often these allow you to solve your problem in less time, with much lower risk of bugs than in C. As always in life, one has to evaluate one's options, consider th…

> to avoid using C where superior alternatives exist is something I agree with.

Who wouldn't?

Post reply on HN