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

171–180 of 181 posts

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

#171

Post by briansmith »

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…

What do you think Rust needs to do to become viable in the embedded world?

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

#172

Post by woodman »

fithisux wrote: post #162
woodman wrote: post #144

Earlier quoted context omitted.

> For example I never could understand why we need enums. > Why should I ever put const in the argument of a function? Reducing potential state and conveying programmer intent. Both lead to safer and more performant code (by way of compiler optimizations).

What you say is incompatible with the "Cross-platform assemble", simple language ideals. If that was the intent why not throw namespaces and other goodies in?

Well those ideals are pretty subjective, I'd say that the ideal language would be flexible, performant, safe and productive. As those goals conflict with one another, the ideal language would find the perfect balance. I don't know if C has found that balance, but it has had a pretty good run.

Defining sets (enums) and memory access constraints (consts). I wouldn't describe that as high level from a conceptual or practical perspective. Namespaces are simple conceptually but not in practice. The same can be said about the beautiful logical consistency of S-expressions.

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

#173

Post by AnimalMuppet »

tome wrote: post #160
AnimalMuppet wrote: post #157

Earlier quoted context omitted.

> 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. Haskell comes to mind. There's a denomination and a religion. I'm not sure that the gospel runs to hundreds of pages, but there are many prophets who tell you that you need to know category theory, so for that sect, yes, i…

> but there are many prophets who tell you that you need to know category theory I challenge you to show me one!

If I knew of a decent search function for HN comments, I could show you several. As it is, I can only offer my memory of what I have read in the comments here.

My impression is that Haskell "experts" here say some variant of "of course all this is obvious because category theory" (implying "you have to know category theory or you're an uneducated heathen") at least three times as often as they say "you don't really need to know category theory".

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

#174

Post by lmm »

snakeanus wrote: post #169
lmm wrote: post #146

Earlier quoted context omitted.

> ehmmmm standard C has floats and doubles. so they are valid C Sure, but the standard says hardly anything about their behaviour, making it practically impossible to write code that actually does anything with floats and doubles that will behave correctly on any standards-compliant C implementation. I suggest you refrain from personal attacks, especially based on your own misreadings of the comment you're replying t…

>but the standard says hardly anything about their behaviour, making it practically impossible to write code that actually does anything with floats and doubles that will behave correctly on any standards-compliant C implementation. No, not really. This reminds me the common "you can't write anything serious in C without undefined behaviour" bs. However, if you DO have a real need of IEEE-compatible floats for whatev…

> However, if you DO have a real need of IEEE-compatible floats for whatever reason, then there is nothing wrong with checking __STDC_IEC_559__ and reporting an error if it is not defined.

Sure - but in that case why not do the same thing for insisting that char be 8 bits?

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

#175

Post by snakeanus »

lmm wrote: post #174
snakeanus wrote: post #169

Earlier quoted context omitted.

>but the standard says hardly anything about their behaviour, making it practically impossible to write code that actually does anything with floats and doubles that will behave correctly on any standards-compliant C implementation. No, not really. This reminds me the common "you can't write anything serious in C without undefined behaviour" bs. However, if you DO have a real need of IEEE-compatible floats for whatev…

> However, if you DO have a real need of IEEE-compatible floats for whatever reason, then there is nothing wrong with checking __STDC_IEC_559__ and reporting an error if it is not defined. Sure - but in that case why not do the same thing for insisting that char be 8 bits?

Except than the fact that it does not limit you except in some very specific cases, unlike the IEEE incompatible floats thing.

If it does limit you somehow and you really need char be 8 bits, then sure.

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

#176

Post by kjs3 »

fithisux wrote: post #105

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 functi…

We've had "better C" since the 70s (since 68 depending on your view of Algol68). Programmers didn't want to use them. I can't tell you how many times I heard "having to to type BEGIN and END sucks" as though that was a valid argument against a language that had none of the issues C has.

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

#177

Post by masklinn »

Anilm3 wrote: post #97
xcgvgh wrote: post #92

Earlier quoted context omitted.

There is no reinventing going on here. In C you have to write relatively low level code. This includes manually calling allocs for objects, which includes the code for checking your arithmetic. At some point you will have to write that code. If you are smart you will wrap it into a function.

I don't see the point of the discussion, that piece of code (or relatively equivalent), is already being performed by a libC function (calloc, in this case), how is that less convenient than you writing it yourself? It has nothing to do with how smart you are or how low level C is, you are effectively reinventing that part of calloc by wrapping malloc.

There's a point to be made that people will be idiots and risk bugs for the sake of efficiency.

That's why OpenBSD has reallocarray(3) (which serves as a fine malloc, though the kernel not having reallocation has mallocarray(9))

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

#178

Post by logicallee »

AnimalMuppet wrote: post #173
tome wrote: post #160

Earlier quoted context omitted.

> but there are many prophets who tell you that you need to know category theory I challenge you to show me one!

If I knew of a decent search function for HN comments, I could show you several. As it is, I can only offer my memory of what I have read in the comments here. My impression is that Haskell "experts" here say some variant of "of course all this is obvious because category theory" (implying "you have to know category theory or you're an uneducated heathen") at least three times as often as they say "you don't really n…

(not to your point but on "If I knew of a decent search function for HN comments"-- just so you know the search https://hn.algolia.com/ is fantastic - I've never failed to find a HN comment)

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

#180

Post by kbart »

briansmith wrote: post #171
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…

What do you think Rust needs to do to become viable in the embedded world?

Ecosystem and community. Most of the time you can find what you need in C already written, in Rust it's do-it-yourself now.
Post reply on HN