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

101–110 of 181 posts

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

#101

Post by kbart »

stupidcar wrote: post #15

Ironic that he begins by taking issue with the idea that you should avoid writing C if you can, then proceeds to provide the best evidence possible for why it's true. 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?

"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 speed and let access hardware easily. Rust might be a step in a right direction, but it still has a looong way to go to become a viable alternative to C in embedded world. Of course, for a modern, high level development (web, mobile etc.), I see no reason to use C (maybe except for tiny libraries or co-routines where speed is critical). C is simply a tool -- it's neither good, nor bad -- and as every tool, it has it's use. You can easily break your fingers with a hammer, but that doesn't mean that it's a bad tool for driving nails in.

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

#102

Post by lultimouomo »

hamiltonkibbe wrote: post #93
lultimouomo wrote: post #54

Earlier quoted context omitted.

> C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever. I'm not an expert on DSP processing in any way, but I'd argue that if the environment is so peculiar that it doesn't have 8-bit bytes, you won't be able to use so many of the (formally optional) parts of C that you might as well call your code "weirdC" and do witho…

You can use char, and for the most part you won't notice any difference, until you start looking at the memory display in your IDE and have a short-lived WTF moment. A c-string looks strange in the memory view because there's a NULL octet between each character but that's an implementation detail that you don't really notice 99% of the time, because everything on the processor is designed to use 16-bit words. If you…

> I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable

I don't think that's fair at all. It's well written and perfectly portable, under that assumption. If that assumption happens to hold for all the systems that could is meant to run on, why shouldn't you make it? Why assuming that unsigned integers overflow to 0 is fair, and assuming 8 bit bytes is not? They are both pragmatic choices. I think arguing that the C standard didn't make the best choice is at the least a reasonable position. Saying that people who disagree with you on this are writing bad code is not the right way to approach the subject, IMO.

> If they're valid C they should work just fine for the most part

I've yet to find a library that is valid C, in the strictest sense of the term - i.e., no floats or doubles, no 8-bit char, no uint8_t, etc. I'm sure there are, among libraries meant to run on DSPs. Does it make sense for them and libraries meant to run on bigger processors to adhere to the same exact standard? I'm not sure.

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

#103

Post by lultimouomo »

dietrichepp wrote: post #62
lultimouomo wrote: post #54

Earlier quoted context omitted.

> C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever. I'm not an expert on DSP processing in any way, but I'd argue that if the environment is so peculiar that it doesn't have 8-bit bytes, you won't be able to use so many of the (formally optional) parts of C that you might as well call your code "weirdC" and do witho…

I think you're underestimating the amount of legacy code that people have. We're not talking about "I have a new processor, let's write code for it." That's unrealistic. It's more like, "I have a new processor, let's get our existing code base working on it, because if we don't, we're going to lose millions of dollars."

That doesn't touch my argument. If you're code is meant to run on DSPs it will already enforce all the relevant rules; if not, you'll have to port it anyway. It's not like your compiler backend that outputs code for DSPs will just compile standard C.

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

#104

Post by logicallee »

dietrichepp wrote: post #73
logicallee wrote: post #65

Earlier quoted context omitted.

This is simply not true. The barrier to a NEW person starting to write C code in 2016 - imagine some 20 year old college student - is "Am I ready to pick a denomination and religion and read hundreds to thousands of pages of gospel?" There is no such barrier with any other language. You literally cannot give any examples of correct C code as a solution to a problem: literally, experts will disagree with you. I've had…

This is exactly my point. You're basically telling me that C is a horrible language. Why? Do you think I disagree with you? Do you think that you're giving me new information? Or are you just doing your part in the language war, perhaps repeating talking points that we're frankly a bit tired of? There are better things we could be talking about.

I didn't say C++ is a horrible language, and I'm sure I didn't say it because I don't really think this.

I would think you're being downvoted because there aren't really any language wars around the choice of C/C++ - it's not like PHP vs Ruby or Python or something. You're imagining a war where there really isn't one.

Usually people writing C or C++ don't have much of a choice, and usually people choose these languages due to the requirements. For example, writing embedded microcontroller code that will run on a $0.70 chip. What are you going to do, write it in Rust?

Nobody would dream of telling Linus Torvalds to refactor the Linux kernel into some other language - it's not just a ridiculous suggestion, it's like asking the United States to move to a different continent - it's a total non sequitur, it's not even in the realm of possibility.

Basically the advice "you should avoid writing C if you can" is totally uncontroversial, and for I would say 99% of people who woke up today, January 15th, 2016, a weekday, and wrote C code, the answer to "can you avoid it" is no. (Not just due to their position/employment but due to the very requirements of the project itself.)

Sure you should avoid writing C and C++ when you can, but for some classes of problems that is "never."

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

#105

Post by fithisux »

The discussion usually boils down to

a. We need a better C

b. We need better programmers.

Personally I believe C tries to hard to be high level instead of what it really is. Newer revisions should try to make it lower level. For example I never could understand why we need enums. Enums are very useful for Java or Golang which are high-level. C never needs enums. Why should I ever put const in the argument of a function? It makes sense for D but for C no. Why should I ever use complex in C. Is there any HW that supports complex numbers? If it becomes standardized, then why not?

C should be good to write kernels and simple utilities and simple compilers. For the rest, use a high-level language.

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

#106

Post by anon1385 »

EliRivers wrote: post #86
anon1385 wrote: post #80

Earlier quoted context omitted.

Saying "just pick the right tool" is a worthless statement when the question is the difficulty of doing that. Would you enter a discussion about curing cancer or depression and announce "just pick the right cure for the disease" and then get upset when people don't agree with you?

Now I can understand your argument. I upvoted you because I like to encourage clarity. This sounds patronising but that's the limitations of a text interface for you. I think you're arguing that sometimes it's difficult to work out what the right tool is for the job. That's true, and not what I'm talking about. I'm saying that the principle of selecting the right tool for the job is sound, and that sometimes C is the…

The chain of discussion:

>Because [C] is simple

>Again, if people can't agree what type to use for integers, then it's not "simple".

>Pick the integer type that is best suited for your use, given your circumstances.

It had nothing to do with deciding to pick C. It was about the difficulty of picking integer types in C being a demonstration of how C isn't simple. That doesn't mean C isn't sometimes the right tool for the job. It does mean that C isn't simple.

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

#107

Post by oldmanjay »

kbart wrote: post #101
stupidcar wrote: post #15

Ironic that he begins by taking issue with the idea that you should avoid writing C if you can, then proceeds to provide the best evidence possible for why it's true. 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?

"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?

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

#108

Post by jevgeni »

stupidcar wrote: post #76
EliRivers wrote: post #45

Earlier quoted context omitted.

Pick the integer type that is best suited for your use, given your circumstances. I can't make it any simpler. There is no one true magical perfect solution for all circumstances in all places at all times. This is why I employ competent programmers; to make these choices. A competent adult would never use a chainsaw or a scalpel except for tasks where nothing else would work. Of course they would. I do, frequently;…

Look, nobody cares how clever and talented a programmer you are, or think you are. Please just drop the unsubtle boasting and passive aggressive insults, they only make you sound like an insecure egotist. Concentrate on the actual issue. In 99.9% of languages, there is one true magical perfect solution to a question as basic as "what type should I use for integers?", and it's "use the integer type". The fact that C n…

The reason why C has several integer types, is because there are different ways to represent integers for computers. Everything else is convention.

I mean, if that bothers you, then meta-programming in Ruby and Python, as well as different lisps should really bum you out.

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

#109

Post by GFK_of_xmaspast »

lultimouomo wrote: post #102
hamiltonkibbe wrote: post #93

Earlier quoted context omitted.

You can use char, and for the most part you won't notice any difference, until you start looking at the memory display in your IDE and have a short-lived WTF moment. A c-string looks strange in the memory view because there's a NULL octet between each character but that's an implementation detail that you don't really notice 99% of the time, because everything on the processor is designed to use 16-bit words. If you…

> I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable I don't think that's fair at all. It's well written and perfectly portable, under that assumption . If that assumption happens to hold for all the systems that…

> If that assumption happens to hold for all the systems that could is meant to run on, why shouldn't you make it?

Because what's going to happen two years down the road when you need to get that code working on a different platform.

(In the old days, they called that thinking "all the world's a VAX", which became "all the world's linux" in the not-quite-as-old days)

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

#110

Post by neopallium »

dietrichepp wrote: post #42
avian wrote: post #5

> Zeroing memory often means that buggy code will have consistent behavior; by definition it will not have correct behavior. And consistently incorrect behavior can be more difficult to track down. I agree that using calloc should not be an excuse for writing sloppy initialization code. But in my experience, inconsistently incorrect behaviour (e.g. heisenbugs that tend to appear and disappear depending on the content…

The tools for rooting out these problems have gotten a lot better, thankfully. I'm very fond of the address sanitizer. Using calloc() everywhere can prevent the address sanitizer from finding problems.

GCC (>=4.8) & Clang now have Address Sanitizer support for fast memory error detection. About a 2x slowdown [1].

0. https://github.com/google/sanitizers/wiki/AddressSanitizer 1. https://github.com/google/sanitizers/wiki/AddressSanitizerPe...

Post reply on HN