[Nagios-devel] Embedded Perl (was check_by_ssh something...)
Posted: Fri Apr 02, 2004 1:44 am
Paul L. Allen wrote:
>>> Perl has a lot of stuff that C lacks without adding libraries that
>>> are not a standard part of C.
>>
>> But not without perl modules.
>
> Really? Regexes are a standard part of the perl language, no modules
> required. If you want regexes in C you have to hunt out non-standard
> (as in not supplied with C compilers and not part of the ANSI standard)
> libraries. The same goes for many perl features.
>
Regexes is sugarcoating for text mangling. Useful indeed, but not
strictly necessary. If you want sockets and some other basic necessities
you need modules.
> C has fairly primitive data structures, but if you grab non-standard
> libraries or write your own code you can have the equivalent of perl's
> arrays and hashes. Etc.
>
Unions and structs are a part of ANSI. It's perfectly acceptable to have
an array of structs containing arrays of structs with arrays of arrays
(or whatever) in them, allowing for infinite depth arrays. Hashes are
convenient, but not necessary since it's perfectly possible for you to
hop the pointer yourself.
>>> Stuff that allows perl programmers to be more
>>> productive and means they don't have to take care to avoid buffer
>>> overflows.
>>
>> There's always a tradeoff in development time if execution time is
>> more important. This is true in perl as well.
>
> Yes, it is. I wouldn't write an operating system in perl,
Correction, noone *could* write an OS in pure perl. In fact, noone can
even write an OS in pure C.
> and I wouldn't write a plugin in C.
Bah. Some plugins should be written in C. Those that parse a lot of text
should be written in perl, and those that rely on external commands for
their data retrieval (like snmpget and fping) should be written in unix
shell (it handles program execution better than perl, since it can
fork() instead of execve()).
>> So what you're saying is;
>> Code it in C, then write some more code so that the third layer of
>> code you write (the perl script) can access the code you wrote first.
>
> So what I'm saying is that for most cases you don't need C. Take a
> look at the perl plugins. NONE of them make use of C-code modules that
> I know of.
The Socket module works with C-code underneath, as does SNMP and File.
>> How does this make development time faster and more efficient?
>
> Most competent programmers understand that programmers generate the
> same average number of *fully* debugged lines of code a day no matter
> which language they write in. It is left as an exercise for the reader
> to compute the average code-density ratio of perl and C.
>
>> Those same functions can be called and linked from any C program
>> without the intermittent layer and the top-level code.
>
> You can do anything from any language, if you try hard enough.
>
My point exactly. Why try 'hard enough' to write it in perl if it needs
C under the hood any way?
>>>> If we set all that aside there is still the issue of having every
>>>> bug ever intoduced in Perl spread to every plugin written in it
>>>
>>> As opposed to every bug ever introduced into the C compiler and
>>> libraries,
>>
>> ... which ALSO fan down into Perl.
>
> ROFL. I wondered if you'd fall for that one. I didn't think you were
> that foolish, but you were. Do you know how much of the perl installation
> process is devoted to detecting known bugs in operating systems and
> compilers and finding the secure alternatives? Perl tries hard to avoid
> hitting on known bugs in OSs and compilers. Perl also does not use every
> feature in C that a C programmer might use.
>
No. I've been writing programs since I was eight but I have never
installed perl (doh!).
On a serious note though; Do you know how many bugs and potential bugs
me and the other Owl developers have fixed in perl 5.8.3? Last time I
checked we were at patch-level 23 (each patch fixes 3 or more bugs).
Patches have been submitted, but it's a serious load of code so I'm
thinking it'll be a while until they're allowed in the tree. Also, we
value security above functionality, which isn't always functional enough
fo
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
>>> Perl has a lot of stuff that C lacks without adding libraries that
>>> are not a standard part of C.
>>
>> But not without perl modules.
>
> Really? Regexes are a standard part of the perl language, no modules
> required. If you want regexes in C you have to hunt out non-standard
> (as in not supplied with C compilers and not part of the ANSI standard)
> libraries. The same goes for many perl features.
>
Regexes is sugarcoating for text mangling. Useful indeed, but not
strictly necessary. If you want sockets and some other basic necessities
you need modules.
> C has fairly primitive data structures, but if you grab non-standard
> libraries or write your own code you can have the equivalent of perl's
> arrays and hashes. Etc.
>
Unions and structs are a part of ANSI. It's perfectly acceptable to have
an array of structs containing arrays of structs with arrays of arrays
(or whatever) in them, allowing for infinite depth arrays. Hashes are
convenient, but not necessary since it's perfectly possible for you to
hop the pointer yourself.
>>> Stuff that allows perl programmers to be more
>>> productive and means they don't have to take care to avoid buffer
>>> overflows.
>>
>> There's always a tradeoff in development time if execution time is
>> more important. This is true in perl as well.
>
> Yes, it is. I wouldn't write an operating system in perl,
Correction, noone *could* write an OS in pure perl. In fact, noone can
even write an OS in pure C.
> and I wouldn't write a plugin in C.
Bah. Some plugins should be written in C. Those that parse a lot of text
should be written in perl, and those that rely on external commands for
their data retrieval (like snmpget and fping) should be written in unix
shell (it handles program execution better than perl, since it can
fork() instead of execve()).
>> So what you're saying is;
>> Code it in C, then write some more code so that the third layer of
>> code you write (the perl script) can access the code you wrote first.
>
> So what I'm saying is that for most cases you don't need C. Take a
> look at the perl plugins. NONE of them make use of C-code modules that
> I know of.
The Socket module works with C-code underneath, as does SNMP and File.
>> How does this make development time faster and more efficient?
>
> Most competent programmers understand that programmers generate the
> same average number of *fully* debugged lines of code a day no matter
> which language they write in. It is left as an exercise for the reader
> to compute the average code-density ratio of perl and C.
>
>> Those same functions can be called and linked from any C program
>> without the intermittent layer and the top-level code.
>
> You can do anything from any language, if you try hard enough.
>
My point exactly. Why try 'hard enough' to write it in perl if it needs
C under the hood any way?
>>>> If we set all that aside there is still the issue of having every
>>>> bug ever intoduced in Perl spread to every plugin written in it
>>>
>>> As opposed to every bug ever introduced into the C compiler and
>>> libraries,
>>
>> ... which ALSO fan down into Perl.
>
> ROFL. I wondered if you'd fall for that one. I didn't think you were
> that foolish, but you were. Do you know how much of the perl installation
> process is devoted to detecting known bugs in operating systems and
> compilers and finding the secure alternatives? Perl tries hard to avoid
> hitting on known bugs in OSs and compilers. Perl also does not use every
> feature in C that a C programmer might use.
>
No. I've been writing programs since I was eight but I have never
installed perl (doh!).
On a serious note though; Do you know how many bugs and potential bugs
me and the other Owl developers have fixed in perl 5.8.3? Last time I
checked we were at patch-level 23 (each patch fixes 3 or more bugs).
Patches have been submitted, but it's a serious load of code so I'm
thinking it'll be a while until they're allowed in the tree. Also, we
value security above functionality, which isn't always functional enough
fo
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]