In Perl it is easier to share code between code-bases. C's verbosity and macro support tends to encourage the development of large complex bodies of macros. Code can't be compiled without the header file defining the macros, and more importantly, the C code often makes no sense unless you are an initiate in that code-base's macro "jargon".

Perl also lets one define language constructs and change the compilation process in seemingly hidden ways, but there is less incentive to use these tricks because Perl is a reasonably succinct language to begin with. Furthermore, doing this kind of magic requires some fairly advanced knowledge of Perl (e.g. understanding symbol tables or the difference between BEGIN and CHECK blocks and the contexts in which they are evaluated). As a result, customized "extensions" to the Perl language tend to be fewer, more well thought out, and better documented than your average C macro header file. (ok, I can see some disagreeing here :-) -- Perl has its own share of horrible code)

Compilation and execution are integrated in Perl whereas C is normally compiled in one phase and executed in another. This makes Perl an ideal tool for solutions where (a) things might need to be patched on the spot (b) bootstrap sequences where tool A1 generates code for tool A2 which then automates the build of tools B1,B2,B3.

In truth any scripting language could play this role. However, I find Perl is a particularly good scripting language choice because it cleanly supports a wide variety of data structures and its support for OOP allows close integration of data and action. When strictures are turned on it also does a reasonably good job of identifying misnamed variables and code that might not behave as intended. This makes it possible for one to maintain even complex scripted solutions with relative ease.

Best, beth