You need a certain amount of complexity to do any particular job. A Saturn V rocket is said to have had seven million parts, all of which had to work. But that's not entirely true. Many of those parts were redundant. But that redundancy was absolutely necessary to achieve the goal of putting someone on the moon in 1969. So if some of those rocket parts had the job of being redundant, then each of those parts still had to do their part. So to speak. They also serve who only stand and wait.
We betray ourselves when we say "That's redundant", meaning "That's useless." Redundancy is not always "redundant", whether you're talking about rockets or human languages or computer languages. In short, simplicity is often the enemy of success.
Suppose I want to take over the world. laughter Not hard to imagine, eh? Simplicity says I should just take over the world by myself. But the reality of the situation is that I need your help to take over the world, and you're all very complex. I actually consider that a feature. Your relationships are even more complex. I usually think of those as features. But sometimes they're bugs. We can debug relationships, but it's always good policy to consider the people themselves to be features. People get annoyed when you try to debug them. "
and the question that came to (my) mind was:
Suppose I implement a faulty algorithm (faulty defined as: -any program in any programming language written as a perfect syntactic representation of the algorithm could be faulted using at least one test case consistent across all implementations) in Perl.
Suppose my Perl implementation happens to also be a faulty implementation of my faulty algorithm (for example, I don't use strict and make a case syntax error, or I switch a $ for a @), but a perfectly valid Perl program. Suppose also that my faulty implementation of my faulty algorithm will give the proper output on all input.
Question:
Does my program have a bug ?