Paul L. Allen wrote:
>> 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.
>
> Gosh, you have unions and structs. Ah well, that's everything you'll ever
> need.
>
For functionality, yes.
>> Hashes are convenient, but not necessary since it's perfectly possible
>> for you to hop the pointer yourself.
>
> Hashes are not just convenient, they solve many problems that would scale
> badly and run very slowly without them.
If the code is written properly, scaling is not a problem. If it isn't,
no language in the world will do the trick for you.
> Of course, you can write your own
> hash code, but good hashing code is difficult to write. Or you could find
> a C library. Or you could use perl.
>
Enter simple mathematics. I argue that good hashing code is trivial to
write as long as it has been properly implemented from the beginning.
>> 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()).
>
> And if you rely on external commands that generate a lot of text that you
> have to parse?
>
man grep
man sed
man awk
man cut
>>> 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.
>
> The socket module is part of the standard distribution. Perl is written
> in C. Neither of those facts mean that it is sensible to rewrite perl
> plugins in C just because perl is written in C.
>
SNMP is not, but I guess you missed that. Also, if I read Karl's
comments on the perl framework correctly, it has almost grown out of its
own usefulness.
>>> 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.
>
> With many more lines of code needed to do so, especially if you need
> text mangling. I made the point about productivity and your response
> ignored it.
>
By reducing the intermittent code layers production times will drop. In
what way did I ignore the productivity issues?
>>> 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?
>
> Why work hard to code something in many lines of C that could be done in
> a few lines of perl? BTW, code generated in C is just a bunch of
> opcodes and data. Why write it in C when it's just opcodes under the
> hood? Why not write raw machine instructions?
>
Now you're just being silly.
>> 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.
>
> You're doing a good job with the patches. But, as you admit, you've
> submitted patches for other things like Apache. You may have the luxury
> of not running Apache until you've done a thorough audit and fixed all
> the holes, most people don't. The same thing goes for perl.
>
Are you expecting a reply to this?
>> Also, we value security above functionality, which isn't always
>> functional enough for the kind of ad-hockery many perl programmers
>> (read script kiddies) indulge in.
>
> Yeah, script k
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]