Deconstructing K&R C Is Dead (2015) • Hacker News Board

Re: Deconstructing K&R C Is Dead (2015)

#141

Post by blub » Thu, May 19, 2016, 9:04 AM UTC

pjmlp wrote: post #128

blub wrote: post #118

Earlier quoted context omitted.

C can be replaced with a reasonable amount of effort with C++. But C++ won't be easy to replace, and I'm not sure it needs to be, since rewrites are highly risky, time consuming and disruptive. With some luck and depending on how the language evolves we might be moving from C++ to a safer C++.

I agree, and that was one of my motivations to adopt C++ instead of C when Turbo Pascal wasn't any longer an option. But using the C++ features that make it safer than C is only an option in small security motivated teams. Sadly the majority of C++ teams, at least in the enterprise space, tends to use it as "C with classes" thus voiding most improvements the language has to offer over plain C.

You've hit on an important point - culture. Every programming community has it and it can enhance or hinder the adoption and usability of a language.

C++ is split between multiple factions. I'm doubtful that the one programming in C with classes is interested in learning e.g Rust.

Re: Deconstructing K&R C Is Dead (2015)

#142

Post by barbs » Thu, May 19, 2016, 9:07 AM UTC

bubuga wrote: post #135

amoruso wrote: post #66

Earlier quoted context omitted.

It's not really ad hominem. More like constructive criticism of his rhetorical style.

> It's not really ad hominem. More like constructive criticism of his rhetorical style. No, it's a blatant ad hominem. The guy invested his time and effort trying to improve the world by writing a technical book, which he then proceeded to give it away for free, and to this we see people like barbs replying with personal attacks accusing the author of being mentally disturbed to the point of requiring therapy. This i…

The term "ad hominem" is typically used to describe the fallacy of attacking the person making an argument, rather than the argument itself. Sure, I'm discussing his character, but I'm not trying to win any argument here - he may be correct in what he's saying.

> The guy invested his time and effort trying to improve the world by writing a technical book, which he then proceeded to give it away for free

And I think this is certainly laudable, especially since they seem to have helped so many people. But he also called the Rails community "pricks, morons, assholes, and arrogant fucks who didn’t care about the art or the craft." and I think he should be held accountable for that, amongst other things.

I wrote a comment about the author's behaviour in public forums and in blogs, something I think he should be held accountable for, and something which I believe hurts both him and the communities he participates in. I believe this is relevant, and I'm entitled to discuss this here.

Re: Deconstructing K&R C Is Dead (2015)

#143

Post by mfukar » Thu, May 19, 2016, 9:28 AM UTC

barbs wrote: post #24

I can't really speak for Zed's expertise and/or value to the programming community. From what I gather, a few of his projects are widely used (Mongrel comes to mind), and he seems to know his stuff pretty well. I also identify strongly with his Programming Motherfucker[0] rant. But man, the guy is insecure to the point of requiring therapy or something. He seems obsessed with his image and status, and the slightest c…

How mature do you think it is that you admit not to know or understand something, and dismiss it as crazy?

Re: Deconstructing K&R C Is Dead (2015)

#144

Post by mfukar » Thu, May 19, 2016, 9:35 AM UTC

ipsin wrote: post #47

To me, C is like PHP (ignoring for a moment that PHP was written in C). You can document its shortcomings, its dangers and all the headache-inducing choices. But while you're doing that, people all over the world are building wonderful and terrible things with it. So you've moving on to Go or Rust? Great! Good choices! But remember that there are people who may disagree and be wrong and also do something interesting…

No language makes it the least bit difficult to write bad code. This is not an argument in favour or against _any_ language.

Re: Deconstructing K&R C Is Dead (2015)

#145

Post by dig1 » Thu, May 19, 2016, 10:20 AM UTC

blub wrote: post #94

kinkdr wrote: post #54

Earlier quoted context omitted.

> Low level languages are tough I disagree. Low level languages, especially C, are the easiest to master. K&R book is the only book you need to read to know everything about C. All you need after you understand the fundamentals is a bit of discipline. C++ on the other hand is extremely difficult to master. Just have a look at the rules for Rvalue references and you will see what I mean. It may be easier for a complet…

I wouldn't say that C is easy to master, but it's not very difficult either. The problem with C is that even a C master can't necessarily write correct code, because C is a very programmer-unfriendly language, making developers remember to do various actions manually and perform error-prone calculations. C++ is definitely harder to master (after many years, I can't say I master every corner of the language), but it's…

> C lost this battle a long time ago... The number of domains where one must use C is shrinking

I doubt that. Kernels, drivers, embedded devices (not IoT), GNU world, are all highly C oriented. Want to develop for a customer with unknown unix variant? Want to develop a tool everyone are going to use, either on Linux/BSD/Solaris? C is the only option.

> but it's much easier to write correct code in C++ and it will be just as fast

Writing correct and fast C++ code at the same time was never an option; even today, with "safe" pointers, people are still confused how to correctly use shared_ptr.

> now that we also have Go and Rust this will accelerate

Some places where C is still a strong contender:

* good tooling - debuggers, memory leak detectors, years of experience with compilers on various platforms

* well understood language - C has dark corners and they are documented well

* interfacing with everything else - from devices to libraries and languages

Re: Deconstructing K&R C Is Dead (2015)

#146

Post by bubuga » Thu, May 19, 2016, 10:33 AM UTC

barbs wrote: post #142

bubuga wrote: post #135

Earlier quoted context omitted.

> It's not really ad hominem. More like constructive criticism of his rhetorical style. No, it's a blatant ad hominem. The guy invested his time and effort trying to improve the world by writing a technical book, which he then proceeded to give it away for free, and to this we see people like barbs replying with personal attacks accusing the author of being mentally disturbed to the point of requiring therapy. This i…

The term "ad hominem" is typically used to describe the fallacy of attacking the person making an argument, rather than the argument itself. Sure, I'm discussing his character, but I'm not trying to win any argument here - he may be correct in what he's saying. > The guy invested his time and effort trying to improve the world by writing a technical book, which he then proceeded to give it away for free And I think t…

> The term "ad hominem" is typically used to describe the fallacy of attacking the person making an argument,

This is a discussion on a book on the C programming language written by someone, and here you are going full throttle on your personal vendetta against the author while saying absolutely nothing regarding the book or the programming language.

> Sure, I'm discussing his character

Precisely.

Go vent your frustrations somewhere else.

Re: Deconstructing K&R C Is Dead (2015)

#147

Post by unwind » Thu, May 19, 2016, 11:22 AM UTC

xenadu02 wrote: post #36

pcwalton wrote: post #8

This is obviously a bitter rant, and devolves into uncomfortably ageist territory about halfway through. I do agree that we should be moving away from C and C++, though. It's pretty simple, really: C was a pretty good language in 1978. We didn't know a lot of things in 1978 that we do now in 2016. It now makes sense to revisit those decisions in light of nearly 40 years of practice. The so-called "PL Renaissance" has…

I'm ready for the hate, so here we go... C was not a well-designed language in 1978. The fact that C arrays decay to pointers without any bounds is single-handedly responsible for a huge chunk, possibly even the majority, of all RCEs, worms, malware, and exploits. Ever. In the history of computing. It was a bad design. It was a bad design in 1978. It was known to be a bad design in 1978. Other languages knew that che…

Maybe you can forgive C for the stupid header compilation model (why let the compiler do what you can make the programmer do by hand?).

This model enables binary-only distribution of libraries, you get the code as a .a (or lib, .so, .dll or whatever) and the API declaration as a header file.

You can write code against a library without having the library, using only the header. You can't do the final linking of course, but you can write the code.

The alternative, I guess, would be to embed this information in the library itself, and have the compiler extract it, which sounds as if it would have been scary from a performance point of view 40 years ago (and also somewhat hard).

Re: Deconstructing K&R C Is Dead (2015)

#148

Post by the_why_of_y » Thu, May 19, 2016, 11:42 AM UTC

mpweiher wrote: post #134

haberman wrote: post #62

Earlier quoted context omitted.

> K&R book is the only book you need to read to know everything about C. All you need after you understand the fundamentals is a bit of discipline. I am a huge C fan but this is not true at all. C has tons of pitfalls, especially with modern UB-aggressive optimizing compilers. There are a lot of rules you need to be aware of that are not naturally-occurring results of the fundamentals.

> especially with modern UB-aggressive optimizing compilers. You put your finger on the problem: "modern UB-aggressive optimising compilers". C, the language, is actually quite simple (if not easy). The crazy stuff that compiler writers have been doing recently while aggressively mis-reading the C standard is the problem and does make things very complicated. Why "misreading"? From 1.1: "The X3J11 charter clearly man…

Your interpretation of "codify common existing practice" would imply that no new compiler optimizations could be implemented since 1990 (when the first version of the standard was published), as any optimization could potentially change the observable execution behavior of an erroneous program that contains UB.

> More from the standard (defining UB):

Your quote is not from the normative text of the standard, but from the non-normative rationale. Note however that it explicitly says that programs that contain undefined behaviors are erroneous, and that the implementation is not required to emit diagnostics for the UB. Pretty clearly this allows implementations to optimize erroneous programs into whatever they think is funny this week.

The normative text of the standard is pretty unambiguous:

    undefined behavior
    behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
    for which this International Standard imposes no requirements

http://www.iso-9899.info/n1570.html#3.4.3

Re: Deconstructing K&R C Is Dead (2015)

#149

Post by the_why_of_y » Thu, May 19, 2016, 11:50 AM UTC

unwind wrote: post #147

xenadu02 wrote: post #36

Earlier quoted context omitted.

I'm ready for the hate, so here we go... C was not a well-designed language in 1978. The fact that C arrays decay to pointers without any bounds is single-handedly responsible for a huge chunk, possibly even the majority, of all RCEs, worms, malware, and exploits. Ever. In the history of computing. It was a bad design. It was a bad design in 1978. It was known to be a bad design in 1978. Other languages knew that che…

Maybe you can forgive C for the stupid header compilation model (why let the compiler do what you can make the programmer do by hand?). This model enables binary-only distribution of libraries, you get the code as a .a (or lib, .so, .dll or whatever) and the API declaration as a header file. You can write code against a library without having the library, using only the header. You can't do the final linking of cours…

Why do you think that parsing a compiler-generated binary representation of an API is more expensive than parsing a human-readable textual representation of the same API? Also, have you ever built a large template heavy C++ program?

Re: Deconstructing K&R C Is Dead (2015)

#150

Post by mpweiher » Thu, May 19, 2016, 12:17 PM UTC

the_why_of_y wrote: post #148

mpweiher wrote: post #134

Earlier quoted context omitted.

> especially with modern UB-aggressive optimizing compilers. You put your finger on the problem: "modern UB-aggressive optimising compilers". C, the language, is actually quite simple (if not easy). The crazy stuff that compiler writers have been doing recently while aggressively mis-reading the C standard is the problem and does make things very complicated. Why "misreading"? From 1.1: "The X3J11 charter clearly man…

Your interpretation of "codify common existing practice" would imply that no new compiler optimizations could be implemented since 1990 (when the first version of the standard was published), as any optimization could potentially change the observable execution behavior of an erroneous program that contains UB. > More from the standard (defining UB): Your quote is not from the normative text of the standard, but from…

> Your interpretation of "codify common existing practice" would imply that no new compiler optimizations could be implemented since 1990

Utter nonsense. I use that word carefully, but in this case it is absolutely appropriate.

Compiler optimisations per an old but very useful definition aren't allowed to change the visible behaviour of programs (in terms of output, obviously they are allowed to change execution times).

For example, even just a couple of years ago the compilers I used would execute a loop that sums the first n integers. Nowadays compilers detect this and replace the loop with the result. While this isn't particularly useful, because probably the only reason you're summing the first n integers in a loop is to do some measurements, it is (a) a perfectly legal optimisation and (b) happened after 1990.

Unsurprisingly, you left out the second part of the (later) definition:

   NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable
    results, to behaving during translation or program execution in a documented manner characteristic of the
    environment (with or without the issuance of a diagnostic message), to terminating a translation or
    execution (with the issuance of a diagnostic message).

Notably absent is "use the undefined behaviour to shave another 0.2% off my favourite benchmark".