Live data from Hacker News

Deep C and C++ (2011)

slideshare.net

51–60 of 243 posts

Re: Deep C and C++ (2011)

#51
post #45
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…

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

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

Re: Deep C and C++ (2011)

#52
post #15

Earlier quoted context omitted.

Arguably if people have such strong understanding of things they will be better programmers too. I would prefer the person who knew what they were doing, because they also know _why_ weird things are weird, and have a better real understanding of what to do and not do. A person who just knows it's "bad code"--but not why--is almost certainly going to leave other bad code from lack of understanding. To pull an example…

However, I'd be concerned that the person with strong understanding of things will simply leave uninitialized static variables lying around in the code simply because they _knew_ it was always initialized to 0. It might work if your entire coding team has that innate understanding, but that is unlikely. Sometimes I think that having deep and expert understanding of a language may cause you to create code that other t…

Static initialisers are a horrible example of "deep" knowledge. Not knowing how they work reveals not only ignorance of syntax but a fundamental lack of understanding of the entire programming and execution environment. Failure to understand your environment inevitably leads to confusion and bad decisions.

Re: Deep C and C++ (2011)

#54
seen this before. whilst its great there are degrees of respect to have for C and C++.

the most productive code i have ever written generally involves me working around the constraints of the language to implement a paradigm which is missing at compile-time, or juggling macros and templates so that i can reduce boilerplate code down to a template with a macro to fill the gaps the template is too featureless to give me (vice versa, the template is there because macros aren't complete enough either).

its good to understand this deep language stuff though because you can understand why C/C++ are limited. for instance the C sequence points limit the compiler in its ability to perform optimisation, as do struct layout rules and many of the other weird and wonderful specifics...

what saddens me most though is that nobody has offered anything to improve C and C++ in these areas which matter most to me... its not even hard. just let the compiler order structs because most programmers don't understand struct layout rules.

its not a good thing that these things are so explicitly specified for the language - its gimping the compilers, which is limiting me. also it results in pointless interview questions about sequence points.. :P

Re: Deep C and C++ (2011)

#55

It is interesting looking at the 'deep' issues of programming languages. This kind of ties in with the "Don't ask me maths questions..." post a few days ago. There really is a lot more to programming than just algorithms, UI design or syntax.

Yes, this worries me. Especially today some people think "great programmers" are the ones who knows all the "fashionable" tools and frameworks, wants to abstract everything (god help him if he install vim in his test environment without a fab file that configures chef) and maybe worships Uncle Bob Knowing how to use Redis is cool, do you know what's even cooler? Being able to write it (or at least knowing how it work…

Even better is getting a programmer that knows enough about making X to not attempt to implement it.

Anyway the programming is such a multi-dimensional evaluation problem that you're just as wrong as you are right.

Think about it - there are so many things programmer SHOULD KNOW it isn't possible to know them all. Let's name them some of them - good architecture style, good API writing skills, good code writing style, good documentation style, company's internal workflow with all its nuances, compiler standards, compiler optimization, non-standard compiler behavior, version control system API, version control innards, database system, file system, low level operating system implementation, kernel innards, non-standard OS behavior, hardware knowledge, driver knowledge, non-standard hardware behavior, hardware compatibility, software-hardware compatibility, etc. (This doesn't cover assembler knowledge, binary represntation of important formats).

You simply have to choose to not learn everything about certain system to be good at other things.

Re: Deep C and C++ (2011)

#56
Great story.

Deep understanding of the language used will make you do a better job.

This reminds me of the story that I've run into once. The junior developer wanted to raise PHP's memory_limit parameter because his code crashed almost every time while writing big file content to the output. He didn't know what output buffering is and that he can turn it off and print the file directly to the output. :D

Re: Deep C and C++ (2011)

#57
post #29

It is interesting looking at the 'deep' issues of programming languages. This kind of ties in with the "Don't ask me maths questions..." post a few days ago. There really is a lot more to programming than just algorithms, UI design or syntax.

I couldn't find that link, could you share it please? Thanks in advance.

Try using hnsearch, it's little publicised but very useful! A search for math (it's the 'Dear Startups... ' link): https://www.hnsearch.com/search#request/all&q=math&start=0

Re: Deep C and C++ (2011)

#58
A fun fact about sequence points. C++ has switched from "sequence points" to "sequenced before/sequenced after" relation. And it is not really "all" previous side-effects that are guaranteed to be visible after the sequence point but only those associated with the sequence point.

In 'foo(b++, a++ && (a+b));' the sequence point introduced by the '&&' only makes the 'a' see the effect 'a++' but the 'b' might not see the 'b++' (function args are not sequenced in C nor C++).

Re: Deep C and C++ (2011)

#59
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?

Re: Deep C and C++ (2011)

#60
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.

Yep, with C and C++ , you can't really say you are an expert.

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.

Post reply on HN