This is an archived low-energy page for bots and other anonmyous visitors.
Please sign up if you are a human and want to interact.
in reply to Reliable software: SOLVED (was: Reliable software OR Is CPAN the sacred cow)
Well, duh. It's very rare for two people's requirements to be exactly the same, so of course the existing modules don't all do exactly what you wish they did. Your definition of "reliable" seems to be "does precisely what I want."
This is the part where you're getting people mad at you. If you run around shouting that people's code is "unreliable" rather than simply not covering some functionality you want (Source filters in eval? Give me a break!), you are certain to annoy them and make them less likely to help you. When you add injury to insult by not offering to help improve what you say is lacking in their modules, what do you expect them to do? Thank you and beg for more of your great wisdom?
CPAN comes with a 100% money back guarantee. Feel free to cash in, or to fork some modules, or to help people fix modules, or whatever it is that you want to do. Meanwhile, the horribly broken e-mail modules that you're complaining about will go back to running most of the Internet's mail. |
Re^2: Reliable software OR Is CPAN the sacred cow
by powerman (Friar) on Sep 15, 2006 at 09:43 UTC
|
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:
- mboxrd - incoming - just delivered by qmail
- mboxcl2 - outgoing - composed by mutt
- ??? - mboxrd incorrectly converted in mboxcl2 by mutt
And you think it's ok? I don't think so... Additional fun here is what term 'mailbox format' has no more sense, because there now 'messages in different "mailbox" format in the single mailbox'. :-/
| [reply] |
|
|
"Reliable" mean I can rely on this software: every documented feature work as expected in all cases.
What you're doing here is adding your own personal requirements and claiming that they are basic necessities. It's just not true. Not everyone needs IPC that supports pipes and lists. Not everyone needs timers that handle someone changing the clock under them. Not everyone needs mailbox parsers that handle all possible formats and survive power failures. So why should they spend their time implementing the features you want, when they already have the ones they need? Adding those features is time-consuming and expensive.
Can you give me full list of perl features which... too complex, or too exotic and which may not be supported by eval()
You picked a great one here. Your complaint about eval is that it doesn't handle source filters? My complaint about perl is that it does handle source filters. I think you're probably the only one on the planet who wants this feature in eval. And the lack of it shows some kind of moral corruption in all perl developers?
| [reply] |
|
|
What you're doing here is adding your own personal requirements and claiming that they are basic necessities. It's just not true.
Yeah, I understand this. But I wish to discuss this situation because I think 'worksforme' software is evil. If I'm only person on perlmonks who think this way - I just wish to know it, what's wrong with this?
Not everyone needs IPC that supports pipes and lists.
Yep. But no one needs IPC which may hands because of lack of timeout, may incorrectly handle signals in some environment (which developer can't prevent because it's environment where his software will be used), etc. Especially no one needs such IPC hidden inside CPAN modules, at least without bold WARNINGs about this in documentation.
Not everyone needs timers that handle someone changing the clock under them.
Can't agree with this. If software has timeout for some operation 15 seconds, but may sometimes (because of NTP daemon, which is part of environment configured by admin of your system without notifying you) finish timeout in 0.5 sec - it's a BUG in this software. Why you think having this bug in nearly all CPAN modules is goodness?
Adding those features is time-consuming and expensive.
Yep. Usually (using clock_gettime(CLOCK_MONOTONIC) isn't more time-consuming than using time() - it may be less portable, but that's another story, portability IS a feature, while reliability isn't a feature).
But if many monks here agree reliability & security is 'mush have' goals, then next we can discuss how to make these goals not so expensive and time-consuming.
| [reply] |
|
|
|
|
| |
|
So your definition of "reliable" is that the software has absolutely no bugs and is 100% secure? I'd love for you to provide a list of software ( any software, in any language ) that fits this. :)
As I understand it your definition of "reliable" is a unicorn. A mythical thing that does not exist, but fun to talk about.
| [reply] |
|
|
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!
I claim pure, unadulterated bovine leavings.
If you can't fix bugs in a piece of software, you're not much of a programmer. Honestly, I'm about ---><-- from putting you in the Noisy Internet Crank bucket forever, and that's after reading three messages from you.
How about dropping the histrionic Smartest-Person-In-The-Room syndrome and actually attempting to work with other people, rather than inventing your own little playrooms? 'cuz you know, some of the people who actually built some of the systems you're dumping on might just care a little bit about this kind of abuse.
| [reply] |
|
|
