Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^9: regexp class (no bugs)

by tye (Cardinal)
on Sep 04, 2011 at 00:09 UTC ( #924029=note: print w/ replies, xml ) Need Help??


in reply to Re^8: regexp class (no bugs)
in thread re: regexp class

No, of course it would not be an "additional feature" request. It would be an original feature request. "This code doesn't have feature $X" is not the same as "This code is buggy". Failing to implement required features makes the code incomplete. It doesn't mean the code contains any bugs.

Code being bug-free obviously does not mean that there are no features that it leaves unsatisfied.

But the empty program successfully implements the following important features:

  1. Compiles without errors
  2. Validates all required inputs
  3. Reproduces itself
  4. Does not allow any SQL injection attacks
  5. Produces all output in UTF-16
  6. Produces all output in 7-bit ASCII
  7. Produces all output in Big5
  8. Logs detailed error reports if any operation it attempts fails
  9. Exits immediately if used as part of any illegal or immoral activity
  10. All output is automatically translated into the viewer's native language, even if there are multiple simultaneous viewers
  11. All network communication is encrypted so that not only can the NSA never decrypt a single byte of it, they can't even detect it

- tye        


Comment on Re^9: regexp class (no bugs)
Re^10: regexp class (no bugs)
by BrowserUk (Pope) on Sep 04, 2011 at 00:22 UTC

    You forgot some: 12. Has minimal cpu, memory & IO requirements :)


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re^10: regexp class (no bugs)
by JavaFan (Canon) on Sep 04, 2011 at 00:38 UTC
    Failing to implement required features makes the code incomplete. It doesn't mean the code contains any bugs.
    That's an utterly weird definition of not having bugs.

    Pray tell me, how do you define a bug? I guess if the requirement is to multiply two numbers $x, and $y, $x + $y isn't a bug, it's merely incomplete (it just doesn't do the right thing yet for inputs other than (0, 0) or (2, 2)).

      I guess if the requirement is to multiply two numbers $x, and $y, $x + $y isn't a bug, it's merely incomplete

      No. And you know it. That's another "silly extremes" example. It's just an attempt to try and "win an argument", rather than further a technical discussion.

      A photo editor that has a red-eye feature that turns all eyes red, has a bug.

      But if it doesn't have a sepia filter, it doesn't have a bug, it just doesn't support that feature.

      The difference is clear and easily understood.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        Bullshit.

        Please read the thread again. And remember who it was who brought up the logical extreme of having no code at all. You wanted to take "golfed code" to an extreme. But golfed code always has a task to perform - if it doesn't perform that task, it's not correct. A program with no code, does not perform the given task. A photo editor that doesn't do anything isn't a bugfree photo editor that's missing a feature.

      Failing to implement required features makes the code incomplete. It doesn't mean the code contains any bugs.
      That's an utterly weird definition of not having bugs.

      Ah, bug religion. Good stuff. I also come from the school of "required features are enhancements, not bugs." Each feature is an enhancement of "nothing."

      Each product release will incorporate required new features, existing feature enhancements, and existing feature bugfixes. If the required features and enhancements are not done, the release is not complete.

      An important issue here is that a product can be released, whether its "dev complete" or not. Now whether those unimplemented features become "bugs" or not really depends on the documentation and marketing. It's a bug for a customer if the docs say a feature exists when it doesn't. Whether its treated as a functional bug or a documentation bug though... well that's a business decision.

      --Dave

        That's all fine and such, but the thread started from the assumption the OP coworker actually have a task to accomplish. Not doing said task isn't "a feature not implemented yet".
        An important issue here is that a product can be released
        "here"? In which sense? The OP is teaching his coworkers regular expressions as tools. To be used to generate the product to be delivered. It's on those tools the OP claimed "less code is less bugs" - to which I objected.

        Now whether those unimplemented features become "bugs" or not really depends on the documentation and marketing.
        Really? That's all? Djees, I wish I had know that years ago. All those time I've been working from specifications and customer wishes - and now you're telling me they don't matter? If I just don't document what I haven't implemented (or haven't implemented correctly), my delivered product doesn't have bugs! Can I keep the test suite, even if it fails?

        So, I guess with the following commands you could remove all the bugs in Perl at once:

        $ git clone ssh://perl5.git.perl.org/gitroot/perl $ git rm pod/* $ echo "Perl is bugfree" > README $ git commit -m "Removed all bugs from Perl" -a $ git push origin blead
        Quick, put in a grant proposal for the perl5 maintenance fund before Nick and Dave do it the hard way!

      I'm with JavaFan on this one. If a product is alleged to have feature X and it doesn't, that's a bug. But I think there is some grey area, due to the vagueness of "alleged". On one hand, if the feature set was defined up front, based on specifications from a "customer", and the delivered product doesn't implement one of those features, that's a bug. OTOH, if it's some kind of commercial product, where feature sets are really driven by internal processes, then a "not implemented yet" feature isn't much of a bug. Of course, the term "bug" itself is vague; every stakeholder has a different idea of what "bug" means. To the coder, a bug might only mean code which contains a flaw. To project management, a bug is a certain kind of record in the tracking system. To a customer, a bug is any variance between the spec and the delivered implementation. And so on. Whose opinion matters most?

      Also, under test-driven development, missing features are usually actual bugs, by just about any definition. This is particularly true if the "not done yet" feature is depended upon by other parts of the system.

      I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
        If a product is alleged to have feature X

        Alleged? By whom? When? On what basis? And whom alleges that someone alleged that the product had this feature?

        The problem with not intelligently differentiating between missing features and bugs, is that it makes it impossible to prioritise properly.

        A bug is (should be) a higher priority than a missing feature. It is something that prevents an implemented feature from being useful until it is fixed.

        A missing feature is lower priority because if the bugs in the implemented code are fixed, a less featured product may still be useful and shippable.

        And that pretty much addresses your "dependant feature" argument. If an implemented feature doesn't work without an unimplemented feature, then both are miss-categorised. The dependent isn't complete, so is not yet an implemented feature. And the dependency is not a feature, but an unimplemented subset of the dependant feature's functionality.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://924029]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (10)
As of 2014-10-23 17:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (126 votes), past polls