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)

Wednesday November 28, 2007
05:47 PM

The Central C Archive Network?

[ #34997 ]

Some interest has been shown by a few People That Matter at OSDC for the idea of cloning a CPAN similar system for C programmers, taking lessons from what worked and didn't work for CPAN.

I'm curious about your feedback on the creation of such a thing.

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'm skeptical. When I turn to CPAN, it's often because I need to quickly satisfy some short-term need mostly unconnected to my existing code. On the other hand, I would guess that most C projects involve enhancing some long-standing infrastructure. This means there's a lot more room for incompatibility between CCAN contributions. It would be an interesting experiment, but I think too many people are locked into their own string libraries, hash tables, etc. for it to work.
    • I don't know, it seems to me that Boost has made a big impact for one. It's everywhere in the C++ world. Sure, legacy projects have lock in -- that's true in every language -- but not new projects.
      • The problem with Boost (and the reason I don't use it) is that to use one Boost library, you almost have to use them all. It's like adding a whole other language: you pay an enormous up-front cost for using a single feature, so it makes sense to avoid Boost unless you have to use many features.
        • Well, maybe that's because they don't have a CCAN to allow cherry-picking features. :-)
        • That's a pity, too. From my understanding (as I try to avoid C++ in general), Boost makes the language much more palatable at the expense of violating the principal design principle: you don't pay for what you don't use. (Then again, I always hate writing code to convince the compiler not to do the wrong thing by default, so maybe C++ isn't very good at that rule itself.)

          • Yeah, C++ may not be for you. I really like the language for its "pay only for what you use" and compile-time evaluation (template metaprogramming) features, but there is significant pain required for each.