6 ms·

Professional C programmer here... The points are great and this is generally a good primer for someone who wants to understand the C mindset. The bit at the e

by nathanb 13y ago

Professional C programmer here... The points are great and this is generally a good primer for someone who wants to understand the C mindset. The bit at the end is a bit off, though. It feels like the author is saying "yeah, C is weird and crufty for historical reasons and some people just use it because they're backward like that". Yeah, I write kernel drivers, but I also just plain like using C, for the same reason that I like driving a manual transmission and usually disable the safety features on stuff: C tries really hard to not get in your way. I enjoy programming in Ruby and mostly enjoy programming in Javascript. But there are times when I think "this is an unnecessary copy...this is inefficient...I wouldn't have to do this if I were writing in C". (There are also times where I think "this one line of code would be over 100 lines of C", but we won't get into that right now...).

adrianm 13y ago
I experienced the inner monologue you describe for several years. It haunted my dreams when working with Ruby. But one day a rhetorical thought suddenly dawned on me that has since changed my perspective quite dramatically... "...if I'm being incessantly bothered by what I perceive as the nagging inefficiencies of some programming language's implementation, maybe I'm not thinking about or relating to programming languages (in the large) in the way I should be..." If all programming languages are merely tools to communicate instructions to a computer, then why is human language not merely viewed by everyone as a means to an end as well? Surely, most would agree that language is more than simply an ends to a mean, and that language does far more than simply transmit information between parties. If efficiency, lack of ambiguity, etc., were the paramount goals of human language, surely formal logic, or perhaps even a programming language for interpersonal communication would be more fitting than natural language! So why do we insist on communicating with each other with what is often such an abstract and ambiguity filled medium? I'll let wikipedia elaborate on my behalf: http://en.wikipedia.org/wiki/Pragmatics http://en.wikipedia.org/wiki/Pragmatics and http://en.wikipedia.org/wiki/Deixis http://en.wikipedia.org/wiki/Deixis http://en.wikipedia.org/wiki/Literature http://en.wikipedia.org/wiki/Literature tldr; it is trivial, even natural for an literate individual with the proper context to understand concepts in language that seemingly transcend the words themselves. These notions would be (and are) exceedingly difficult to formalize, and any formal expression of these ideas would cause exponential growth of the output. Ever try explaining a joke to someone who didn't "get it"? It takes a lot more "space" to convey the same sentiment than to someone who "got it". So what has this crazy rant have to do with anything? Well, aside from revealing I am a complete nerd, it speaks to my approach to software engineering today. We have to let go of the machine if we ever want to really move the state of the art forward. There are an infinitude of expressible ideas, but lacking the proper medium to abstract the expression of these ideas formally (like natural language and our brains do, well, naturally) we will never get a chance to find out what we don't know! "We're doing it wrong" is not exactly the sentiment I'm trying to express, but it's sorta that. Maybe. Hope this comment made any sense. :) It's 4 AM after all.
- nathanb 13y ago
  I'm afraid I couldn't hang on for the ride...perhaps I'm like the one who doesn't get the joke and needs the much lengthier explanation! It sounds like you're saying that programming languages are constrained on two ends: on one end by being too tied to the underlying microarchitecture, and on the other end by being interpreted by our minds which think about programming in terms of language features rather than Platonic ideals. Assuming I've come at least close to understanding your point, I guess what you're saying is that by thinking too closely about what I'm trying to do at a low level, I'm negatively affecting my ability to write idiomatic Ruby code to do useful things? This is probably true; it's one of the curses of being a kernel developer. I think you want people who care deeply about how bits are laid out in memory being the ones who are writing your operating system.
  - adrianm 13y ago
    I wasn't trying to insult you or anything, my comment was just my (extremely) sleepy attempt to express an idea that I've had shuffling around in my mind for a while now. At times there's nothing I want to do more than solder components onto a circuit board and make a radio or something. It's really, really gratifying to make something work that's so "magical" (from a certain point of view, radio is pretty magical to me) and completely understand how everything works from start (bare materials) to finish (a working radio!). I guess what I was trying to say was that if I would ever want to make a CPU comparable to, say, what Intel produces today, I'd have to give up my soldering gun and any notion of manufacturing the CPU with any discrete process (like soldering individual transistors) and instead adopt an entirely new approach - like maybe electroplating - in any event, it's one that allows me to make incredibly powerful things at the expense of being able to "use my hands". Experts are always going to need to know (and I mean really KNOW) the underlying fundamentals of their field regardless of how "high level" their work becomes - see theoretical physics, et al. With that in mind, I think people who care deeply about how bits are laid out in memory are exactly the same people who will always be at the forefront of computer science and software engineering - even if 99% of their practical output in life is at a level much higher than bits. :)
- Double_Cast 13y ago
mtdewcmu 13y ago
The joy of C isn't just in writing it. It's also about getting back a program that runs unreasonably fast at the end. Sometimes you really can tell.
- pkolaczk 13y ago
  Most of this impression is usually caused by the combination of the following things: * fast startup * programs in C usually do much less with more code than high level languages Once the project gets really big and complex, C starts to get slower and harder to optimize than some higher level languages (e.g. dynamic dispatch tends to be slower in C than in C++ or Java).
  - deeviant 13y ago
    Dynamic dispatch in C? There is none. There bigger a project is, the more stuff it does. If a language does this stuff slow(aka ruby), then it will not run faster no matter what buzz words you invoke.
    - mtdewcmu 13y ago
      Yeah... C's dynamic dispatch can be slow or fast. It's up to you, because you get to write it yourself.
      - pkolaczk 13y ago
        It can't be as fast as in VM-based languages, because the code (typically) can't self-optimize / modify itself according to the usage patterns to inline dynamic calls. This is the stuff that VM can do, because it has much more information. This is one of the reasons a general sorting method like qsort is so slow in C compared to general sorting method in Java (Collections.sort). Sure, you can specialize manually or do some macros, but such manual approach gets hairy pretty quickly for something more complex than a simple sorting method.
        13y ago
huherto 13y ago
I fell in love with C, 25 years ago, but then I moved into enterprise applications using higher level languages. How is the job market place for C programmers? I would imagine that younger programmers don't go that route.
- seren 13y ago
  If you work on (real time) embedded systems, it is pretty much a C and C++ world, at least for the lower layer, and middleware part. You can pretty easily work in Automotive, Aeronautics, Robotics, Defense, etc...
- nathanb 13y ago
  I started as a professional C programmer in 2007 at the age of 24, if that gives you any useful demographic data :)
scott_s 13y ago
Perhaps I can state a point simpler than another poster. "this is an unnecessary copy...this is inefficient...I wouldn't have to do this if I were writing in C" You should then ask yourself: does the inefficiency matter? Will it make the program noticeably slower? If not, then you can safely ignore the lack of machine efficiency and embrace the gain in programmer efficiency.
- nathanb 13y ago
  A valid question...sometimes it does. Sometimes it doesn't. Sometimes you think it won't, and then it does and you have to do some herculean things later to make it scale. Also, I think it's a fallacy to say that higher level languages necessarily mean more programmer efficiency. When I'm doing network programming in C, here's what it looks like: * Define a struct whose field layout matches the wire format * Cast the incoming buffer to that struct * Done By contrast, Ruby requires me to marshal data and painstakingly extract each field...all because it tries to abstract away the fact that memory is a flat array of bytes. Yeah, much of the time I'll be more productive in a higher-level language. But there are problem domains where that is not the case.

by nathanb 13y ago

adrianm 13y ago

I experienced the inner monologue you describe for several years. It haunted my dreams when working with Ruby. But one day a rhetorical thought suddenly dawned on me that has since changed my perspective quite dramatically... "...if I'm being incessantly bothered by what I perceive as the nagging inefficiencies of some programming language's implementation, maybe I'm not thinking about or relating to programming languages (in the large) in the way I should be..." If all programming languages are merely tools to communicate instructions to a computer, then why is human language not merely viewed by everyone as a means to an end as well? Surely, most would agree that language is more than simply an ends to a mean, and that language does far more than simply transmit information between parties. If efficiency, lack of ambiguity, etc., were the paramount goals of human language, surely formal logic, or perhaps even a programming language for interpersonal communication would be more fitting than natural language! So why do we insist on communicating with each other with what is often such an abstract and ambiguity filled medium? I'll let wikipedia elaborate on my behalf: http://en.wikipedia.org/wiki/Pragmatics http://en.wikipedia.org/wiki/Pragmatics and http://en.wikipedia.org/wiki/Deixis http://en.wikipedia.org/wiki/Deixis http://en.wikipedia.org/wiki/Literature http://en.wikipedia.org/wiki/Literature tldr; it is trivial, even natural for an literate individual with the proper context to understand concepts in language that seemingly transcend the words themselves. These notions would be (and are) exceedingly difficult to formalize, and any formal expression of these ideas would cause exponential growth of the output. Ever try explaining a joke to someone who didn't "get it"? It takes a lot more "space" to convey the same sentiment than to someone who "got it". So what has this crazy rant have to do with anything? Well, aside from revealing I am a complete nerd, it speaks to my approach to software engineering today. We have to let go of the machine if we ever want to really move the state of the art forward. There are an infinitude of expressible ideas, but lacking the proper medium to abstract the expression of these ideas formally (like natural language and our brains do, well, naturally) we will never get a chance to find out what we don't know! "We're doing it wrong" is not exactly the sentiment I'm trying to express, but it's sorta that. Maybe. Hope this comment made any sense. :) It's 4 AM after all.

nathanb 13y ago
I'm afraid I couldn't hang on for the ride...perhaps I'm like the one who doesn't get the joke and needs the much lengthier explanation! It sounds like you're saying that programming languages are constrained on two ends: on one end by being too tied to the underlying microarchitecture, and on the other end by being interpreted by our minds which think about programming in terms of language features rather than Platonic ideals. Assuming I've come at least close to understanding your point, I guess what you're saying is that by thinking too closely about what I'm trying to do at a low level, I'm negatively affecting my ability to write idiomatic Ruby code to do useful things? This is probably true; it's one of the curses of being a kernel developer. I think you want people who care deeply about how bits are laid out in memory being the ones who are writing your operating system.
- adrianm 13y ago
  I wasn't trying to insult you or anything, my comment was just my (extremely) sleepy attempt to express an idea that I've had shuffling around in my mind for a while now. At times there's nothing I want to do more than solder components onto a circuit board and make a radio or something. It's really, really gratifying to make something work that's so "magical" (from a certain point of view, radio is pretty magical to me) and completely understand how everything works from start (bare materials) to finish (a working radio!). I guess what I was trying to say was that if I would ever want to make a CPU comparable to, say, what Intel produces today, I'd have to give up my soldering gun and any notion of manufacturing the CPU with any discrete process (like soldering individual transistors) and instead adopt an entirely new approach - like maybe electroplating - in any event, it's one that allows me to make incredibly powerful things at the expense of being able to "use my hands". Experts are always going to need to know (and I mean really KNOW) the underlying fundamentals of their field regardless of how "high level" their work becomes - see theoretical physics, et al. With that in mind, I think people who care deeply about how bits are laid out in memory are exactly the same people who will always be at the forefront of computer science and software engineering - even if 99% of their practical output in life is at a level much higher than bits. :)
Double_Cast 13y ago

mtdewcmu 13y ago

The joy of C isn't just in writing it. It's also about getting back a program that runs unreasonably fast at the end. Sometimes you really can tell.

pkolaczk 13y ago
Most of this impression is usually caused by the combination of the following things: * fast startup * programs in C usually do much less with more code than high level languages Once the project gets really big and complex, C starts to get slower and harder to optimize than some higher level languages (e.g. dynamic dispatch tends to be slower in C than in C++ or Java).
- deeviant 13y ago
  Dynamic dispatch in C? There is none. There bigger a project is, the more stuff it does. If a language does this stuff slow(aka ruby), then it will not run faster no matter what buzz words you invoke.
  - mtdewcmu 13y ago
    Yeah... C's dynamic dispatch can be slow or fast. It's up to you, because you get to write it yourself.
    - pkolaczk 13y ago
      It can't be as fast as in VM-based languages, because the code (typically) can't self-optimize / modify itself according to the usage patterns to inline dynamic calls. This is the stuff that VM can do, because it has much more information. This is one of the reasons a general sorting method like qsort is so slow in C compared to general sorting method in Java (Collections.sort). Sure, you can specialize manually or do some macros, but such manual approach gets hairy pretty quickly for something more complex than a simple sorting method.
      - 13y ago

huherto 13y ago

I fell in love with C, 25 years ago, but then I moved into enterprise applications using higher level languages. How is the job market place for C programmers? I would imagine that younger programmers don't go that route.

seren 13y ago
If you work on (real time) embedded systems, it is pretty much a C and C++ world, at least for the lower layer, and middleware part. You can pretty easily work in Automotive, Aeronautics, Robotics, Defense, etc...
nathanb 13y ago
I started as a professional C programmer in 2007 at the age of 24, if that gives you any useful demographic data :)

scott_s 13y ago

Perhaps I can state a point simpler than another poster. "this is an unnecessary copy...this is inefficient...I wouldn't have to do this if I were writing in C" You should then ask yourself: does the inefficiency matter? Will it make the program noticeably slower? If not, then you can safely ignore the lack of machine efficiency and embrace the gain in programmer efficiency.

nathanb 13y ago
A valid question...sometimes it does. Sometimes it doesn't. Sometimes you think it won't, and then it does and you have to do some herculean things later to make it scale. Also, I think it's a fallacy to say that higher level languages necessarily mean more programmer efficiency. When I'm doing network programming in C, here's what it looks like: * Define a struct whose field layout matches the wire format * Cast the incoming buffer to that struct * Done By contrast, Ruby requires me to marshal data and painstakingly extract each field...all because it tries to abstract away the fact that memory is a flat array of bytes. Yeah, much of the time I'll be more productive in a higher-level language. But there are problem domains where that is not the case.