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

Re: Deep C and C++ (2011)

#171

Post by dman » Wed, Oct 23, 2013, 5:30 PM UTC

pjmlp wrote: post #16

easytiger wrote: post #12

Earlier quoted context omitted.

In c and c++ understanding these things can save you 1 day a week on average.

I would say even more than that. C and C++ can make someone loose days to track down issues, in this day and age, where teams are distributed with lots of offshoring and various skill levels across development sites. My last C++ project was in 2006, since then I have only used C++ outside work. At work our focus has been in JVM and .NET languages. I don't miss playing the C++ fireman expert role that has to fix a sta…

Lets abandon quantum mechanics because most people dont understand it.

Re: Deep C and C++ (2011)

#172

Post by kerkeslager » Wed, Oct 23, 2013, 5:30 PM UTC

ryandrake wrote: post #140

hacknat wrote: 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…

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 standard, because I know that eventually someone will have to maintain the code who doesn't know that. I don't particularly care what the standard says there: the code shouldn't assume detailed understanding of the standard, which isn't realistically a valid assumption.

Re: Deep C and C++ (2011)

#173

Post by yngccc » Wed, Oct 23, 2013, 5:30 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…

they are unfashionable not because they are written in C/C++. Programming at the end of the day is just not that hard, what is hard is domain knowledge, you can write a compiler in any language.

Re: Deep C and C++ (2011)

#174

Post by agentultra » Wed, Oct 23, 2013, 5:36 PM UTC

sanderjd wrote: post #147

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'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 sound, and a host of other details that must be mastered before one can really make it sing.

I can study music theory for years and it won't help me play the violin well. It will make composition easier and assist me as I adapt myself to the instrument. However one still has to master the instrument and I see the two being complementary and distinct skills.

The metaphor holds together when you start thinking about the breadth of languages available. For example, my primary instrument is guitar. I've been playing for years and have a good grasp of it. However I recently took up the violin so that I could learn to fiddle and play some bluegrass and Irish folk tunes. I still can't play a single tune well on the violin but my knowledge of string instruments and music theory is certainly making my adoption faster than someone who is starting from the very beginning.

However one must be careful with breadth. I could try to learn to play the mandolin after I've "finished," with the violin. And perhaps a banjo after that. However mastery requires a deep, intimate knowledge: you have to spend time with an instrument, learn its quirks, and practice with it every day. Even the best guitar players practice every day. You don't have enough time in this world to master every stringed instrument.

Harder still is the transition to a completely different class of instrument. Mastering drums and guitar is not impossible but rather difficult as knowledge of one doesn't offer much in learning about the other. Learning C is one thing but learning Common Lisp is learning an entirely different model of computation. Having a grasp of the fundamental theories will help some here but nothing you know about C compilers will help you to understand CL (and vice versa). So be even more suspicious of the depth of a programmer's knowledge if they list more than a few languages on their resume if those languages span entire classes of computational models.

And I don't think there's enough time in this world for even a very competent programmer to say they are a master of more than one or two languages.

Update Added a paragraph on computational models and expanded the instrument metaphor.

Re: Deep C and C++ (2011)

#175

Post by dman » Wed, Oct 23, 2013, 5:37 PM UTC

jgreen10 wrote: post #59

pacaro wrote: post #9

I've been a C developer (among other things) for about 20 years or so, but I've always described my C++ skills as being "in the C with objects" range, I might have to change that to being "nearly in the C with objects" range.

I didn't have any trouble with the C examples, but with C++ it just puzzles me why people would want to use a language like that in the first place. What does it buy you except bigger head aches?

RAII.

Re: Deep C and C++ (2011)

#176

Post by xradionut » Wed, Oct 23, 2013, 5:40 PM UTC

NAFV_P wrote: post #154

I signed up with HN to get articles related to C, yet they're about as common as hens teeth. I've just executed a word search on this comments page: 18 instances of "static", but no mention of "volatile" or "extern", which is the same situation in several textbooks on C. The article mentioned looking at the assembler output of a program, but didn't give any hints on where to learn some assembly.

You need to learn the history of HN and realize that Lisp is the original hacker language.

As for assembly, there's been several lists of "free" computer books post that have included assembly tutorials.

Re: Deep C and C++ (2011)

#177

Post by agentultra » Wed, Oct 23, 2013, 5:52 PM UTC

cousin_it wrote: post #167

alexk7 wrote: post #136

Earlier quoted context omitted.

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.

That's a fair point, and math notation is famously more ambiguous than programming languages. But it seems to me that the concepts denoted by math notation (e.g. numbers, arithmetical operations, functions...) are inevitable and unique, while the concepts denoted by strings in a programming language are much fuzzier and more arbitrary (except for languages that have a denotational semantics, which are few and far bet…

People often speak of the axioms in maths when they describe how, "elegant," and, "consistent," it is. I'm not a mathematician but I've read Gödel's "proof" and know enough that there are no guarantees. It matters what system of axioms you use and requires the reader to recognize the limits of those axioms in defining the system of logic they they imply. Or some such.

Point being that there is no system that is complete. There are large bodies of mathematics these days that have specialized their notations and axioms to their domains. It is incredibly difficult to maintain a masterful knowledge of all of their idiosyncrasies and notations.

Re: Deep C and C++ (2011)

#178

Post by ksk » Wed, Oct 23, 2013, 5:54 PM UTC

sanderjd wrote: post #151

ksk wrote: post #126

Earlier quoted context omitted.

>You're the one forcing the choices. "I would much rather [a person do X] than [a person do Y]" I parse this kind of statement as a person doing X is more important than a person doing Y. I stated that I thought both were achievable. How have you parsed it? Also trivia implies some memorized factoids. The entire point of the article is having an understanding of the underlying implementation of the compiler, maybe th…

> 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 the standard or the preferred wine of the standardization committee(its called beer I think :P). I guess we have a difference of opinion on that.

Also the difference in syntax and translation unit/linker behavior is not a random fact. Its the culmination of the thought process that goes into designing the language and also knowing a bit of the theory behind classical compilers/linkers.

Re: Deep C and C++ (2011)

#179

Post by benched » Wed, Oct 23, 2013, 5:58 PM UTC

revelation wrote: post #77

What bizarre nonsense. I hope nobody thinks this level of (mis)understanding is replacement for understanding, you know, how to program . The majority of this is undefined behavior or implementation details of your compiler. If you rely on that, I don't want your code anywhere near my machine.

I am trying to find a way to reconcile two realities. On one hand, whenever I encounter books or articles on language legalese (particularly in C and C++), it is always immediately apparent that I'm somewhat out of my depth, despite programming in C and C++ for 20 years. I can follow the reasoning, but I almost never spot the finer problems myself.

On the other hand, I can and have written large, complex games that run well and appear to be just fine from the user's point of view. I can seemingly write reams of code without ever thinking of such issues, except when they trip up the compiler or cause detectable bugs. I find I very, very seldom need to think of the lawyerly issues at work, or in personal projects, and to my knowledge, nobody has suffered materially for it. (Granted, I am writing games and not NASA software.)

Whenever these types of issues come up, I always think: "Wow, I know less than I thought. This seems serious?" And yet I never seem to see real-world consequences. This seems strange to me.

Re: Deep C and C++ (2011)

#180

Post by devcjohnson » Wed, Oct 23, 2013, 5:58 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…

Me too reply...

Don't get cute and always prefer to explicitly state in code what you get for free implicitly. The maintenance guy that follows behind you will be the one to espouse how clever you actually are. That's how I mentor junior engineers as a general rule.