Deep C and C++ (2011) • Hacker News Board

Re: Deep C and C++ (2011)

#181

Post by kenko » Wed, Oct 23, 2013, 6:13 PM UTC

NAFV_P wrote: post #159

agentultra wrote: post #131

I love this presentation. It led me to read Expert C Programming [1] by Peter Van Der Linden. My knowledge of C had vastly improved after reading that book (and subsequently C++). Even if you're not a C programmer I would recommend the book as the anecdotes alone are worth reading for the questions that it encourages you to ask. I've since come to believe that reading the specifications and having the attention neces…

"C programming is a craft that takes years to perfect. A reasonably sharp person can learn the basics of C quite quickly. But it takes much longer to master the nuances of the language and to write enough programs, and enough different programs, to become an expert. In natural language terms, this is the difference between being able to order a cup of coffee in Paris, and (on the Metro) being able to tell a native Pa…

"where to get off" has at least three interpretations---the one you note, one in which you insulte the Parisienne (why a Parisienne? Why not the English word, which has the advantage of being gender-neutral, "Parisian"?), and the (presumably) intended interpretation, what exit to use.

Re: Deep C and C++ (2011)

#182

Post by daenz » Wed, Oct 23, 2013, 6:19 PM UTC

kerkeslager wrote: post #172

ryandrake wrote: post #140

Earlier quoted context omitted.

I cant even remember how many times I've had to ask co-workers, "So, that's what you think your code will do... what does the standard say?" or, "Why did you use int there when the API spec defines the parameter as taking size_t?" or, "You think that code in your inner loop will compile to one machine instruction. Have you actually looked at the compiler's output?" and the looks/responses that I got. There seem to be…

There's a deeper problem here, though. If you're asking, "So, that's what you think your code will do... what does the standard say?" the problem isn't really that they don't know the standard, it's that they've written the code in a way where it's ambiguous what it does. If I see static int i; in code, I'm going to change it to static int i = 0; even if I know that static integers are initialized to 0 in the standar…

You nailed it. Standards are nice and all, when they're perfectly unambiguous, and when everyone follows them exactly. That is not the real world. Writing code clearly and explicitly has far more reward for the effort put into it than learning all the standards pedantically.

Re: Deep C and C++ (2011)

#183

Post by Someone » Wed, Oct 23, 2013, 6:53 PM UTC

ksk wrote: post #100

Someone wrote: post #91

Earlier quoted context omitted.

"Great mathematicians can understand the theory and just apply it to whatever problem they come across." I don't think you know how great mathematicians think. http://en.wikipedia.org/wiki/57_(number)#In_mathematics "Although 57 is not prime, it is jokingly known as the "Grothendieck prime" after a story in which Grothendieck supposedly gave it as an example of a particular prime number."

>I don't think you know how great mathematicians think. I'm confused. What is your basis for that statement? If you you know how they think why don't you just express it? :-S I am sorry, I have no clue what your point is, or even if you have one.

Grothendieck is/was (according to Wikipedia, he is still alive, but he retired from mathematics years ago (http://en.wikipedia.org/wiki/Alexander_Grothendieck#Politics...) a great mathematician who knows/knew a lot about prime numbers, but he could not apply that 'to every problem he came across'. In fact, when pressed to give a concrete prime number, he came up with 57.

That makes him a counterexample of the claim that all great mathematicians can apply heir knowledge.

If he were a computer scientist, he would have written several brilliant papers about the pros and cons of various properties of programming languages, but he would not be able to write a compiler for any language or even to write a program.

Re: Deep C and C++ (2011)

#184

Post by pjmlp » Wed, Oct 23, 2013, 7:01 PM UTC

xradionut wrote: post #170

pjmlp wrote: post #60

Earlier quoted context omitted.

That is the same with any language. An expert should not only know the language as defined by the standard or canonical implementation, but also the majority of implementations for the said language and consequent deviations from the official language semantics. Ergo, no one is actually a real expert in a specific language.

Kay is an expert in Smalltalk and Wirth is an expert in Oberon. Stroustrup is an expert at nailing legs to a dog and calling it an octopus.

> Kay is an expert in Smalltalk and Wirth is an expert in Oberon.

No, they are experts on the implementations they created, not on the other ones that were created.

Re: Deep C and C++ (2011)

#185

Post by geoka9 » Wed, Oct 23, 2013, 7:06 PM UTC

agentultra wrote: post #131

I love this presentation. It led me to read Expert C Programming [1] by Peter Van Der Linden. My knowledge of C had vastly improved after reading that book (and subsequently C++). Even if you're not a C programmer I would recommend the book as the anecdotes alone are worth reading for the questions that it encourages you to ask. I've since come to believe that reading the specifications and having the attention neces…

> It seems to me that learning 1 - 2 languages to this level of detail is worthwhile.

I think it's feasible with an "old-school" (compact) language like C or Go. But take something like C++ or Scala, for example, and the task quickly becomes impossible.

Re: Deep C and C++ (2011)

#186

Post by pkolaczk » Wed, Oct 23, 2013, 7:07 PM UTC

pandaman wrote: post #127

cousin_it wrote: post #104

Earlier quoted context omitted.

My comment was talking about a stronger kind of consistency, maybe "inevitability" would be a better word for it. You could make many different tiny changes to the rules of C and still end up with a workable programming language. (Many people have done that, there are tons of languages derived from C.) You could say that the rules of C are "random" - after learning the first n rules, you cannot use logic to predict t…

My guess you apply your experience with some bizarre language (PHP?) to C, which you never learned. C and C++ are internally consistent in the same way a math theory is. Many programming languages are not, indeed. > You could make many different tiny changes to the rules of C and still end up with a workable programming language. (Many people have done that, there are tons of languages derived from C.) Coincidentally…

Saying that C++ is internally consistent at all is a huge exaggeration. Actually I'd be very careful with stating it is more consistent than PHP. Both have many sharp-edges and in both there are plenty of features that feel "tacked on" and are non-orthogonal to each other. E.g. why I can't make a generic (template) function virtual or why I cannot overload some overloadable operators to have exactly same semantics as the builtin ones.

Re: Deep C and C++ (2011)

#187

Post by pjmlp » Wed, Oct 23, 2013, 7:11 PM UTC

kamaal wrote: post #84

pjmlp wrote: post #51

Earlier quoted context omitted.

> You'll find them toiling away in anonymity, working in research labs, working on compiler optimizers or operating systems or some other domain with challenging technical problems. Sadly you are required to move for such jobs, which is not always an option.

And best of all is such things are not fashionable. Take a round of HN or any other place where programmers hang around. Take a note of how many articles, blogs posts, essays, tiny libraries, frameworks etc are written for languages like Javascript, or Python, or Ruby, or Java. Compare this with C. There is a degree of serious technical focus that languages like these demand for big projects. Embedded systems, Operat…

Small rant, so take it with a grain of salt.

Personally I don't care about C, due to its unsafe by default design and my background in safer languages for systems programming.

I got my first computer, a Timex 2068, at the age of 10. Spent two years mainly playing games and eventually started looking into programming.

When I learned C, at the age of 16, I already knew BASIC (Spectrum, GW, Quick, Turbo), Assembly (Z80, x86, 68000), Turbo Pascal.

So C was for me a bit "meh" language, given that Turbo Pascal gave me much more, granted except for portability. So I quickly jumped to C++, which allowed me some strong typing comfort and higher abstractions in a forced C land.

Regardless of the language, when I was 18, I had already coded compilers, graphics applications, GUI prototypes, MS-DOS drivers.

Nowadays kids seem just to do JavaScript/Python/Ruby frameworks for generating web pages.

Re: Deep C and C++ (2011)

#188

Post by sanderjd » Wed, Oct 23, 2013, 7:12 PM UTC

ksk wrote: post #178

sanderjd wrote: post #151

Earlier quoted context omitted.

> Also trivia implies some memorized factoids. The entire point of the article is having an understanding of the underlying implementation of the compiler, ... That's some of the point of the article, but some of it is also about memorized factoids. There is a lot of focus on what different versions of the C standard say about different things, which is just factoids. There is a lot of focus on how different declarat…

If you had to write code for a platform and the only compiler available was C89 compatible, you better know what syntax the C89 standard says is legal and not legal. Its simply called knowing the language. By your implied definition I see every single thing that anyone reads/learns as a 'factoid'. In my mind factoids imply some useless disconnected fact like the number of restricted keywords or the number of pages in…

It is probable that we have a disagreement about what counts as a "factoid", and maybe it's not a great word to be using ( I took it from the parent), but I do think there are real differences between some things you're conflating. Working within the framework of your example, I think understanding how compilation units and the linker work is far more fundamental than knowing when the the "static" keyword impacts linking and when it doesn't. If I know that I need some way to make my variable visible outside my compilation unit, I can look up the syntax to do it ("factoid"), but if I don't understand how linking works at all, I'm missing a more fundamental mental model. Of course, I absolutely think that a C programmer should know the syntax, it's just less important to remember such things than to understand the model.

Re: Deep C and C++ (2011)

#189

Post by sanderjd » Wed, Oct 23, 2013, 7:16 PM UTC

agentultra wrote: post #174

sanderjd wrote: post #147

Earlier quoted context omitted.

It's wonderfully frustrating that there is truly so much to learn that even the study of programming languages, which is an incredibly tiny field relative to the whole of human knowledge, it is still necessary to make depth vs. breadth trade-offs. I find your choice to focus more on depth appealing, but almost immediately feel a sense of loss for all the breadth such a focus would require giving up. I think a better…

It boils down to learning a handful of languages enough that you can make some meaningful contributions or a single language deep enough that you can have a meaningful discussion. Neither approach forgoes learning fundamental theory. I equate learning to master C like learning to master a particular instrument like the violin; it requires knowledge of the instrument's construction, the physics of how it produces soun…

Well said. Thanks for your thoughts.

Re: Deep C and C++ (2011)

#190

Post by kyllo » Wed, Oct 23, 2013, 7:57 PM UTC

nraynaud wrote: post #48

this has nothing to do with understanding but more with memory. What's drowning people in C and even more in C++ is not the logic of the language, but the sheer number of tricky concepts and the pure accumulation of information (it is reflected on the size of the specs). There is also the fact that very often non-specified behavior, or implementation dependent or everything else that is not cool does not lead to a wa…

What's drowning people in C and even more in C++ is not the logic of the language, but the sheer number of tricky concepts and the pure accumulation of information (it is reflected on the size of the specs).

I agree, and I'd add that C/C++ is a bit of a leaky abstraction layer over assembly. It aims to be portable, but true portability means that the C/C++ developer really shouldn't have to know/care what assembly instructions the compiler/linker is emitting, because all of that stuff depends on which chip architecture you're targeting.

Basically, coding in C/C++ requires an intimate knowledge of how the compiler works, and sometimes even how the target chip works. C/C++ software projects of notable size oftentimes cannot be simply recompiled/linked to a different target architecture without changing things like compiler flags, the makefile, and even the application code itself. That makes it a non-portable, leaky abstraction, and dramatically increases the amount of knowledge that's required of a C/C++ developer.