Your definition of "reliable" seems to be "does precisely what I want."Pure nonsense. "Reliable" mean I can rely on this software: every documented feature work as expected in all cases. "Does what I want" mean have some features.
There a lot of modules in CPAN which "does what I want, and much more", but I can't use them because I open their source and in few minutes/seconds discover bugs which nature say: hey, my author does't think about this, and that, and about that critical issue too while developing me. This in turn mean there no sense in patching/bugreporting, just because author doesn't have reliability and security in his goals, and I can't reach these goals in this situation!
(Source filters in eval? Give me a break!)Hmm. Can you give me full list of perl features which... too complex, or too exotic and which may not be supported by eval()... or do()... or require()... or, better, let's remove them from perl at all! Eval manual say: "EXPR is parsed and executed as if it were a little Perl program.", and doesn't say "except source filters feature", so it MUST support everything which supported in "little Perl program". It doesn't. (I hit this bug when I experimented with html template engine based on source filters.)
Meanwhile, the horribly broken e-mail modules that you're complaining about will go back to running most of the Internet's mail.YEAH. And that's terrible, if you ask me!!!
Yesterday I've found bug in qmail/mutt: qmail store messages in mboxrd format, while mutt incorrectly convert them into mboxcl2 format. So my mailbox have messages in 3(!) different formats:
In reply to Re^2: Reliable software OR Is CPAN the sacred cow
by powerman
in thread Reliable software: SOLVED (was: Reliable software OR Is CPAN the sacred cow)
by powerman
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |