Live data from Hacker News

Deep C and C++ (2011)

slideshare.net

131–140 of 243 posts

Re: Deep C and C++ (2011)

#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 necessary to delve into these kinds of details and ask the right questions is important for mastery. It seems to me that learning 1 - 2 languages to this level of detail is worthwhile. I've been thinking of cutting back the number of languages I, "know," down to just those for which I am familiar with the specifications and how they're compiled, assembled, etc. Everything else is superficial.

Sometimes all you need is just a cursory knowledge to get something done and the ends justify those means. However if you really love your craft then mastery should be the goal, no? It seems to be the difference between, "getting something working," and, "pushing the boundaries of what is possible."

[1] http://www.amazon.ca/Expert-Programming-Peter-van-Linden/dp/...

Re: Deep C and C++ (2011)

#132

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…

I think the point was that mathematics relies on a small set of postulates from which you can derive everything else. Changing a postulate results in a separate system. The same is true in programming languages, but the number of postulates is very large compared to mathematics to the point that their utility is greatly reduced. And also there are so many languages each with its own postulate set that it's really inelegant when compared to mathematics.

Another way to put it is, learning the postulates for langx doesn't provide enough value for many to be worth doing.

Re: Deep C and C++ (2011)

#133
post #10

People complain loudly about gotchas in JS, but when you look at what C++ programmers have to contend with...

For the niches that JS fills, a clear language with few pitfalls would be best.

C++ has a different niche. On top of that, everyone acknowledges the warts of C++, but they're largely necessary for either backward compatibility or performance reasons.

Re: Deep C and C++ (2011)

#136
post #45

Earlier quoted context omitted.

>In an interview, I would much rather hear a person say something about a statically declared variable with no initialization being poor code to leave behind for the next person than some arcana about the standard. Why are you forcing those two choices? One could be well-versed with the arcana AS WELL AS point out that bit about statically declared variable .. The problem IMO is most programmers cargo-cult/copy-paste…

> Great mathematicians can understand the theory and just apply it to whatever problem they come across. As someone who's both a mathematician and a programmer, I think that analogy glosses over an important difference, which is also relevant to why many people refuse to memorize certain things. Good mathematical theories are internally consistent in a very strong sense. When you're learning them, you feel like you'r…

Standard mathematical notation is not inevitable and is not unique. It is on par with most programming languages for being quite random. Both programmers and mathematicians use an imperfect tool (programming language, mathematical notation) to achieve goals that may, or may not, be eternal.

Re: Deep C and C++ (2011)

#137
post #128

Earlier quoted context omitted.

Yes, you could say that the C standard is a formal theory. It won't be a very interesting one to a mathematician though, because it's huge and describes only one thing, C. There are no special considerations to single out that theory from a huge pool of similar ones. It's like devoting your life to the study of one particular differential equation with a thousand terms, which was written by a committee. Why not the o…

I am not against your POV ! I think we largely agree on most things here. I wanted to correct what I perceived to be a mischaracterization of my 'off the cuff' analogy.

Yeah, from your reply to patrickmclaren I understood the point you were trying to make, and I agree with you. Sorry for misunderstanding you so persistently.

Re: Deep C and C++ (2011)

#138
post #103
post #8

Earlier quoted context omitted.

But we should certainly be aware both of what the language requires of the compiler and of potential pitfalls.

The problem there is that while compilers have been getting better, they're nowhere near beating good programmers (yet ?). Languages other than C/C++ get in the programmer's way and prevent them from using "maximum" cleverness, and that means the best java/c# programs are simply always going to be slower than the best c/c++ programs.

That's true on balance, which is why C/C++ is still typically faster than managed languages. In many particular cases it's not true, however. Consider "register" or "inline" directives, which have been advisory for a long time.

Re: Deep C and C++ (2011)

#139
post #132

Earlier quoted context omitted.

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…

I think the point was that mathematics relies on a small set of postulates from which you can derive everything else. Changing a postulate results in a separate system. The same is true in programming languages, but the number of postulates is very large compared to mathematics to the point that their utility is greatly reduced. And also there are so many languages each with its own postulate set that it's really ine…

>I think the point was that mathematics relies on a small set of postulates from which you can derive everything else.

And I agree, this is one of the assertions my opponent has made. I did not go to refute it because, if not outright false, it's disingenuous.

>Another way to put it is, learning the postulates for langx doesn't provide enough value for many to be worth doing.

This is also true, same goes for everything else. I make money using C - I learn C's postulates. If somebody paid me to use topology - I'd learned topology postulates. What would be stupid if I were paid to use topology but said: "it's hard to learn and it makes no sense for me because I don't like mathematics and don't know any other math discipline so why would I all of sudden learn topology's postulate when I can copy formulas from the net and ask questions on manifoldoverflow.com?"

Re: Deep C and C++ (2011)

#140
post #7

I'm not so jaded as to think that deep language understanding isn't a useful or good thing, and I'd like to think I have some myself. However, deep language understanding is not what separates the great engineers from the good ones. In an interview, I would much rather hear a person say something about a statically declared variable with no initialization being poor code to leave behind for the next person than some…

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 very few programmers who understand the language & their compilers deeply enough, or even care to learn. These programmers are far more productive because they're not constantly guessing or assuming how their code might work.
Post reply on HN