7 ms·

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

by ksk 13y ago

>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/stackoverflow their way into programming jobs. No, that does not mean you never ask for help. No, that does not mean you never copy-paste. (Phew!) Its sort of like when you're learning math. Great mathematicians can understand the theory and just apply it to whatever problem they come across. Its because they have a very solid foundation underneath them. They wield their knowledge like tools and can just build anything with those tools because they understand those tools very well. Most students however just learn the patterns of the problems. And once they know enough patterns they can solve problems which fit into one of those pre-understood patterns. The people who are deeply knowledgeable about the language are good at knowing the boundaries of the language, knowing when you're using constructs that are not valid-syntax (which still compile), etc. The social aspect of 'good comments' , 'readable code' or 'maintainable code' is also important. You can have programmers that do both. Ofcource those programmers will never work for 'you' (not you, personally..) because most programming jobs are shitty and do not require programmers of that skill. 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.

pjmlp 13y ago
> 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.
- kamaal 13y ago
  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, Operating systems, Databases, compilers etc. A big part of software world uses these languages on a daily basis. But there is no where the kind of hipster crowd, these languages have the web frameworks or languages have. Even if you spend some time searching for resources on the net, there are few that teach deep C skills. There might be one or two books out there which haven't been updated in 2 decades. By and large, these are unfashionable fields to work in. The barrier to entry is really high, Success comes only with seriousness and application of well focused effort, mistakes are expensive and they warrant serious RTFM'ing the hard way- to write to some real serious code.
  - ksk 13y ago
    I don't know why you have C up on some pedestal. Its not really a 'hard' language to learn or grasp. Sure some languages take less time to learn than others. But every single language makes tradeoffs. For e.g performance vs productivity/usability OR static typing vs dynamic typing is a common theme when discussing C vs {Java, Python, blah}. Also, your comments falsely compare the difficulty of the TASK with the difficulty of the IMPLEMENTATION/LANGUAGE. They are not the same! Take any advanced applied math algorithm and implement it in Python. Its not 'easy' by any means. The domains you mentioned have a higher barrier to entry because the tasks themselves are difficult. The languages and technology used are simply variables in a much larger optmization problem that also includes monetary/human/computing/time resources as variables.
  - yngccc 13y ago
    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.
  - pjmlp 13y ago
    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.
    - kyllo 13y ago
      Nowadays kids seem just to do JavaScript/Python/Ruby frameworks for generating web pages. That's progress, IMHO. Instead of distributing application binaries carefully targeted to each type of user machine, we only have to run the application on one server machine (or a cluster of them) in a central location and can serve the application over the network. We now have code-generating frameworks that help automate away much of the tedious, repetitive parts of implementing an application. It's not a good thing that software development is hard. It does mean that you're a very smart and hard-working person if you're able to do it effectively. But it's not a good thing for society that you need to be so smart and hard-working in order to do it. It is, however, a good thing that it's not as hard as it used to be. The fact that a software developer has to do and know less today than they did 20-30 years ago, just to build an application and distribute it to a large number of users, is a sign of progress.
- ksk 13y ago
  >Sadly you are required to move for such jobs, which is not always an option. True. Talent going to waste is sadly nothing new. Has happened, will continue to happen. :(
cousin_it 13y ago
> 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're learning something eternal that could not possibly turn out any other way. If you forget half of calculus, you can reconstruct it from the other half, and the reconstruction will be unique. The details of programming languages, like C and especially C++, are not like that. For many mathematicians who would otherwise make excellent programmers, the details of C will feel like something not worth memorizing, because they don't make sense - they are not an inevitable, provably unique solution to any problem. To a mathematically inclined mind, programming concepts form a hierarchy depending on how "inevitable" and worth memorizing they are. Concepts like computability, lambda calculus or big-O complexity are near the top, syntaxes of specific languages are lower down, and API details are at the bottom. That also reflects the rates of change: math doesn't change, languages change every decade, and APIs change every year. If I want to hire a programmer for the long term, as opposed to getting quick help on my current project, I will be mostly asking them about concepts from the top of the hierarchy, not what static means in C. Of course some people will disagree with me and demand detailed knowledge about static or templates or whatnot, while dismissing mathematical questions as "puzzles". Maybe that's also a valid style of programming, I'm not sure...
- tel 13y ago
  A thousand times this. Mathematicians are spoilt by maths riches of eternal problems. CS ought to be too, but so many are instead fascinated by the 10 year, 2 year, 1 week problems around the fashion of a programming tool. No wonder everyone is always talking about the rapid pace of learning in high technology.
- ksk 13y ago
  No, I too am talking about a hierarchy of internally consistent knowledge. Have you implemented a compiler or a interpreter for a popular language? I could be wrong but I strongly suspect you haven't. If you have ever implemented a compiler you understand the language at a fundamental level and when stumped with a bug or a highly technical puzzle or what have you - you get that "aha" moment where its like "Ofcource ! How else could it be. This language feature must be using this construct because of X or Y reason and the compiler has to work this way because this part here doesnt allow for it to work any other way, etc ,etc and the optimizer has xyz amount of scratch registers so abc condition could never happen, and on and on."
Someone 13y ago
"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 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."
- ksk 13y ago
  >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.
  - Someone 13y ago
    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_and_retreat_from_scientific_community 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.
kazagistar 13y ago
The other day we were discussing interview questions at work. The idea came up to ask people to solve a simple programming task in an ugly, arcane, and generally incorrect way; something like "Implement X as a python one liner, using at least three methods from itertools". The good candidates would point out that it really should not be done that way. But puzzle questions like that are silly anyways, so whatever.
epsylon 13y ago
> 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 .. You're the one forcing the choices. He's just saying that one should consider another metric to gauge developers, that is knowledge of good software practices over deep language arcana wisdom. And he's saying that whatever the knowledge depth (or lack of) of a candidate on the C or C++ language, he'll choose the one with better software practices. (Of course, the two metrics are slightly correlated, but being an expert on C trivia doesn't necessarily makes you a good developer) Life is too short to become an expert on C's dark corners, and I'm not even talking about C++'s.
- ksk 13y ago
  >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 the implementation of the standard library, or the OS or the hardware ADDS to your knowledge about C making you a much more complete/well-rounded developer. Calling it C trivia is baffling to me. >Life is too short to become an expert on C's dark corners, and I'm not even talking about C++'s. Agreed !
  - sanderjd 13y ago
    > 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 declaration syntax behaves (statics, linker visible, etc.), which is just factoids.
    - ksk 13y ago
      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.

by ksk 13y ago

pjmlp 13y ago

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

kamaal 13y ago
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, Operating systems, Databases, compilers etc. A big part of software world uses these languages on a daily basis. But there is no where the kind of hipster crowd, these languages have the web frameworks or languages have. Even if you spend some time searching for resources on the net, there are few that teach deep C skills. There might be one or two books out there which haven't been updated in 2 decades. By and large, these are unfashionable fields to work in. The barrier to entry is really high, Success comes only with seriousness and application of well focused effort, mistakes are expensive and they warrant serious RTFM'ing the hard way- to write to some real serious code.
- ksk 13y ago
  I don't know why you have C up on some pedestal. Its not really a 'hard' language to learn or grasp. Sure some languages take less time to learn than others. But every single language makes tradeoffs. For e.g performance vs productivity/usability OR static typing vs dynamic typing is a common theme when discussing C vs {Java, Python, blah}. Also, your comments falsely compare the difficulty of the TASK with the difficulty of the IMPLEMENTATION/LANGUAGE. They are not the same! Take any advanced applied math algorithm and implement it in Python. Its not 'easy' by any means. The domains you mentioned have a higher barrier to entry because the tasks themselves are difficult. The languages and technology used are simply variables in a much larger optmization problem that also includes monetary/human/computing/time resources as variables.
- yngccc 13y ago
  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.
- pjmlp 13y ago
  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.
  - kyllo 13y ago
    Nowadays kids seem just to do JavaScript/Python/Ruby frameworks for generating web pages. That's progress, IMHO. Instead of distributing application binaries carefully targeted to each type of user machine, we only have to run the application on one server machine (or a cluster of them) in a central location and can serve the application over the network. We now have code-generating frameworks that help automate away much of the tedious, repetitive parts of implementing an application. It's not a good thing that software development is hard. It does mean that you're a very smart and hard-working person if you're able to do it effectively. But it's not a good thing for society that you need to be so smart and hard-working in order to do it. It is, however, a good thing that it's not as hard as it used to be. The fact that a software developer has to do and know less today than they did 20-30 years ago, just to build an application and distribute it to a large number of users, is a sign of progress.
ksk 13y ago
>Sadly you are required to move for such jobs, which is not always an option. True. Talent going to waste is sadly nothing new. Has happened, will continue to happen. :(

cousin_it 13y ago

> 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're learning something eternal that could not possibly turn out any other way. If you forget half of calculus, you can reconstruct it from the other half, and the reconstruction will be unique. The details of programming languages, like C and especially C++, are not like that. For many mathematicians who would otherwise make excellent programmers, the details of C will feel like something not worth memorizing, because they don't make sense - they are not an inevitable, provably unique solution to any problem. To a mathematically inclined mind, programming concepts form a hierarchy depending on how "inevitable" and worth memorizing they are. Concepts like computability, lambda calculus or big-O complexity are near the top, syntaxes of specific languages are lower down, and API details are at the bottom. That also reflects the rates of change: math doesn't change, languages change every decade, and APIs change every year. If I want to hire a programmer for the long term, as opposed to getting quick help on my current project, I will be mostly asking them about concepts from the top of the hierarchy, not what static means in C. Of course some people will disagree with me and demand detailed knowledge about static or templates or whatnot, while dismissing mathematical questions as "puzzles". Maybe that's also a valid style of programming, I'm not sure...

tel 13y ago
A thousand times this. Mathematicians are spoilt by maths riches of eternal problems. CS ought to be too, but so many are instead fascinated by the 10 year, 2 year, 1 week problems around the fashion of a programming tool. No wonder everyone is always talking about the rapid pace of learning in high technology.
ksk 13y ago
No, I too am talking about a hierarchy of internally consistent knowledge. Have you implemented a compiler or a interpreter for a popular language? I could be wrong but I strongly suspect you haven't. If you have ever implemented a compiler you understand the language at a fundamental level and when stumped with a bug or a highly technical puzzle or what have you - you get that "aha" moment where its like "Ofcource ! How else could it be. This language feature must be using this construct because of X or Y reason and the compiler has to work this way because this part here doesnt allow for it to work any other way, etc ,etc and the optimizer has xyz amount of scratch registers so abc condition could never happen, and on and on."

Someone 13y ago

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

ksk 13y ago
>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.
- Someone 13y ago
  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_and_retreat_from_scientific_community 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.

kazagistar 13y ago

The other day we were discussing interview questions at work. The idea came up to ask people to solve a simple programming task in an ugly, arcane, and generally incorrect way; something like "Implement X as a python one liner, using at least three methods from itertools". The good candidates would point out that it really should not be done that way. But puzzle questions like that are silly anyways, so whatever.

epsylon 13y ago

> 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 .. You're the one forcing the choices. He's just saying that one should consider another metric to gauge developers, that is knowledge of good software practices over deep language arcana wisdom. And he's saying that whatever the knowledge depth (or lack of) of a candidate on the C or C++ language, he'll choose the one with better software practices. (Of course, the two metrics are slightly correlated, but being an expert on C trivia doesn't necessarily makes you a good developer) Life is too short to become an expert on C's dark corners, and I'm not even talking about C++'s.

ksk 13y ago
>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 the implementation of the standard library, or the OS or the hardware ADDS to your knowledge about C making you a much more complete/well-rounded developer. Calling it C trivia is baffling to me. >Life is too short to become an expert on C's dark corners, and I'm not even talking about C++'s. Agreed !
- sanderjd 13y ago
  > 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 declaration syntax behaves (statics, linker visible, etc.), which is just factoids.
  - ksk 13y ago
    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.