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

151–160 of 181 posts

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

#151

Post by Roboprog »

hamiltonkibbe wrote: post #95
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?

You voluntarily code in C for the same reason that your OS kernel's 'yield' is written in assembly. How do you push the addressing mode register to the stack when switching to another task in your high level language of choice?

I like how the old Borland Turbo Pascal had little extensions to let you move data between program variables and registers, as well as put in little bits of assembler.

Of course, that only worked on x86 on MS-DOS :-(

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

#152

Post by Roboprog »

pjmlp wrote: post #124
benbenolson wrote: post #111

Earlier quoted context omitted.

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

It is not a joke, rather the conclusion of someone that was already dismayed with C back in the mid-90's. > 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. Except for those little compiler specific little issues, it seems: http://blog.llvm.org/2011/05/what-every-c-programmer-should-... http://blog.llvm.org/2011/05/what-every-c-…

Agreed. (yes, did a lot of C in the mid/early 90s that ran on sundry unices, DOS, OS/2, Windows & VAX). Ouch.

"The C Programming Language" isn't that great of a book, either. I had FAR better luck making sense of C (after having been in school for almost 4 years, and working part time on another language for almost 2 years) with the book "C, An Advanced Introduction" (1st version, not "ANSI Edition"), by Narain Gehani. For somebody transitioning from real high level languages, the array/pointer/string swamp was a real source of anti-productivity fun and games until explained by somebody other than its creators.

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

#153

Post by Roboprog »

nabla9 wrote: post #83
dietrichepp wrote: post #49

Earlier quoted context omitted.

X-to-C compiler isn't as nice as it could be, because you're writing code for some weird chip and need to twiddle some bits for IO using a macro defined in a header somewhere, and that doesn't play nicely with your pet X-to-C compiler. Not an ideal situation, for sure, but a real one.

It's possible for translator understand headers and macros and generate bindings for them. Even for function macros. For example, GNAT has macro binding although it's not complete. Btw. There is nothing "pet" in X to C translators. You pay good money for a good Ada to C compiler.

Or an RPG II to C translator/compiler :-)

A job I had in the early 90s, maintaining and extending such...

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

#154

Post by rc4algorithm »

lmm wrote: post #150
rc4algorithm wrote: post #149

Earlier quoted context omitted.

> The overwhelming majority of C implementations additionally define the values of all-bits-zero floats and pointers. So... Clang and GCC? Regardless, you're ignoring the obvious difference: that isn't POSIX- or ISO-defined at all. If you choose to use it, you're using a weird dialect. Might as well just switch to Cyclone.

> that isn't POSIX- or ISO-defined at all. If you choose to use it, you're using a weird dialect. People used C (even on multiple compilers) long before POSIX or ISO. You're putting the standardization cart before the compatibility horse.

Yeah, let's revert to 1988! Great solution! Muchly of advance!

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

#155

Post by Roboprog »

rkangel wrote: post #139
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.

The XAP processor architecture use in CSR Bluetooth Chips (design orginally from Cambridge Consultants) is one such processor. On it: A 'byte' is 16 bits. A word is 16 bits (so sizeof(int) == 1) A function ptr is 24 bits (so sizeof(Fx) == 2) CSR have sold well over a billions chips. There is a strong argument that this is the 3rd most popular architecture family after ARM and X86/64. Things that x86 programmers do th…

Would you port x86 code, like say the Apache web server, to this chip? Or is it basically a memory constrained little device that you are writing a driver for, from scratch?

Seems like you would learn the rules, even though they are a bit odd, easily enough while writing something from scratch, or maintaining an existing (somewhat) small driver program.

Agreed, though, be aware (or just beware?) that this chip is quite different, and new skills MUST be learned.

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

#156

Post by pcwalton »

ue_ wrote: post #38
pcwalton wrote: post #29

Earlier quoted context omitted.

As a matter of fact, GCC extensions are de facto standards at this point. Clang had to copy most of them. Same with bytes not being 8 bits. Nobody will ever make a system where that's not the case anymore. You'd break de facto compatibility with almost all C code for no reason. Market realities trump making systems "for fun".

>You'd break de facto compatibility with almost all C code for no reason. The authors of that code should have written portable code if they didn't want it to break.

If you're designing a new ISA, it's extremely difficult to succeed in the market no matter what you do. But one excellent way to guarantee you won't succeed is to have that attitude toward your developers.

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

#157

Post by AnimalMuppet »

logicallee wrote: post #65
dietrichepp wrote: post #41

Earlier quoted context omitted.

This comment only fans the flames of language war, it doesn't contribute to the discussion.

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…

> 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, it's hundreds or thousands of pages.

Lisp also has a denomination and a religion, but the sacred texts may be shorter.

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

#158

Post by GFK_of_xmaspast »

lultimouomo wrote: post #131
GFK_of_xmaspast wrote: post #109

Earlier quoted context omitted.

> 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)

> Because what's going to happen two years down the road when you need to get that code working on a different platform. And what happens when the different platform handles overflow differently? Or has non-IEEE floats? Or breaks whatever assumption the C standard already makes? Here's the thing: C is already built on assumptions, which might or might not hold for a specific platform. Choosing which assumptions we ho…

If you're in a situation where you need specific implementation details of floating point arithmetic, then may the devil have mercy on your soul, because god certainly won't.

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

#159

Post by ori_b »

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…

A better solution in this case is to fill the memory with junk -- 0xdeadbeef is a popular solution.

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

#160

Post by tome »

AnimalMuppet wrote: post #157
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…

> 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!

Post reply on HN