Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

  (email not shown publicly)

Journal of Alias (5735)

Sunday November 11, 2007
08:04 PM

The demise of glorious ignorance

[ #34880 ]

Annoyed and somewhat confused by some the crazy stuff I'm needing to do in order to get the Strawberry additional libraries to install, I've decided to finally end my intentional ignorance of all things C and picked up the cow book from my local book shop (it had the most content of building code, pre-processor stuff, and C modules, which is where my biggest needs are).

I consider this a failure, as I have long-valued NOT having to know C in order to work with Perl. And on dozens of occasions it has helped to be able to play the "I have no idea what you are talking about, explain it in Perl terms" card with people that seem to assume all Perl programmers (or at least all CPAN authors) know C.

Given the number of people that have problems with unreliable C modules, I also consider it a positive thing that all my modules are pure Perl. The temptation to do things in a faster but more evil or harder-to-maintain fashion has also been one I haven't had to deal with.

The only positive is probably with regards to career options, as some of the better-paying toolchain/build-system jobs (including one recent $US200k one in New York) require C knowledge.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I recently had to start doing a fair amount of C coding and it seems like you have to shift your mindset to think in terms of addresses, pointers, and data types. The first two weeks were quite painful, but after that everything just clicked, I've written two linux kernel modules over the course of about two months. Switching off between perl and c isn't that hard either once you've done it once. Good luck, and don't give up!

    • After an hour of skimming the book, C (particularly with respect to the preprocessor) looks scarily like Perl, just with less hand-holding.

  • I feel like we're pretty much in the same boat: I do not like C, I prefer to stay away from it as much as possible. It's a difficult language, and it seems to me like the bulk of the work by P5P is working around nonportability issues of C. If I can, I'd like to spend the little time I have on other things.

    But sometimes you just have to bite the bullet.

    So... how do you like the Cow book? Is it worth picking up?

    (Other people may reply too :))
    • The Cow book's decent. If you already have some familiarity with C, you might not learn a lot of new things.

      I'm enjoying Robert Love's Linux Kernel Programming (even though it has a slightly more Linux than POSIX bent, it's good for Unix-like system programming in general, if you read past the titular bias) and found the GDB coverage of C in a Nutshell very worthwhile.

    • Since I care less about the fine details of the language, and my main interest is in the toolchain-related areas (preprocessor, compilers, linkers, modules, paths, etc) I'm found the cow book to be excellent, since it contains a relatively large number of chapters about those topics.

      Most of the other books (from "C for Dummies" to "The Complete C Reference") spent a lot more time on the details of the language itself, and relatively little time on the toolchain.

      And from the perspective of a CPAN'y person, t
      • Thank you. I've been looking for a good way to learn the toolchainy parts of C. I knew there had to be a resource somewhere!
        • Please note there's two cow books, "C" and "Practical C Programming", I got the "Practical" one.