Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: When is it better to NOT release a new module?

by diotalevi (Canon)
on Nov 02, 2005 at 16:44 UTC ( #504991=note: print w/replies, xml ) Need Help??


in reply to When is it better to NOT release a new module?

Your module appears to be a source code filter operating on general purpose perl. Such things should never be released. They're evil, nasty things and cause problems for other people.

  • Comment on Re: When is it better to NOT release a new module?

Replies are listed 'Best First'.
Re^2: When is it better to NOT release a new module?
by BUU (Prior) on Nov 02, 2005 at 22:02 UTC
    Your module appears to be a source code filter operating on general purpose perl. Such things should never be released. They're evil, nasty things and cause problems for other people.

    Ya know, I too once had this opinion. I even asked Ovid about it. I felt his response was enlightening enough to reproduce here:

    Now that I have the lying out of the way, I can understand the hesitation about them. I worked for Rentrak for a year and they did something very similar (but on a much smaller scope) to what I'm trying to do, but they did it with Filter::Util::Call. Naturally, when I first started working with this I complained heartily to my programming friends about using a source filter in production code. And not just any old production code, either. We're talking about code that is rightfully called "enterprise class." And you know what? In the entire time I used it, I only stumbled across one bug (and admittedly it was a bugger to track down.) I know what the bug is and it's not going to be in my version :)

    So after working with a source filter for over a year, what did I discover? Source filters, when done properly, can make programming much, much easier. I didn't realize how much I missed signatures until I had them again. I also didn't realize how much I missed having an entire class of bugs pretty much disappear because I had signatures. For the one bug that was caused by this source filter, programming was much more productive and bug free.

    I was wrong about source filters. I used to think they were terribly evil and should not be used, but now I realize (as with all dogmatism) that this is not universally the case. Admittedly, source filters generally need to be some of the most heavily tested code, but the payoff can be huge.

    But serious programmers don't use source filters, right? Don't tell that to Damian and Ingy, two well-known and respected programmers who are quite happy to reach for source filters when that's the solution to a thorny problem. Those, naturally, are two that come to mind but there are plenty of others. Source filters are to be used sparingly, but it's not the case that they should never be used. They are not evil, just dangerous.



    This was taken from his journal at: http://use.perl.org/~Ovid/journal/22152. The following discussion also links to this node: Re: Use method/function signatures with Perl which discusses it further.

      [Edited Its wrong of me to characterize everything done by a particular author this way. There are a small set of examples of bugs in his published work and some things like years passing while bug fixes submitted to rt.cpan.org aren't applied.] Ingy is no example. Bugs in his work are unsurprising and regular. I don't know whether this is related to his use of source filters or not.

      I checked Damian's list of categorized modules for stuff that used something from Filter. Here's how it breaks down for his source filtering modules. It works out that while Damian has written several things using source filters, he has only one thing that isn't marked experimental that actually uses source filters that would be available in production. [Edited He writes some fabulous stuff but there isn't any evidence that he's written anything using source filters that he considers worthy of running in production.]

      Modules you aren't supposed to use anyway

      • Lingua-Romana-Perligata
      • Perl6-Currying
      • Perl6-Export
      • Perl6-Placeholders
      • Perl6-Rules
      • Switch

      Attribute-Handlers-Prospective is the only module that was superceded by other things. You shouldn't use it.

      He said Inline-Files is production worthy but its marked as experimental in its pod?

      He uses Smart-Comments and Toolkit as development aides. It turns out that you aren't supposed to use Smart-Comments in production anyway - its a design feature that they're easy to remove. So production code doesn't even touch a source filter.

      Regarding Ovid's code. Its much easier to have a source filter when you're running it against code you control and with some known code standards. Its much less sane to do that when you're releasing things onto CPAN where it will have to deal with anything that's potentially available.


      I assert that Ovid's anecdotal evidence does not indicate that source filters are ok for general use on CPAN.

        Its much less sane to do that when you're releasing things onto CPAN where it will have to deal with anything that's potentially available.
        Excuse me? Since when is it a requirement that anything released on CPAN needs "to deal with anything that's potentially available"? Answer: never.

        CPAN never has, and never will put any requirements on the code stored there, other than its license should allow distribution. If there were such requirements, we wouldn't have a gazillion Class::* modules, many of which don't play nice with each other.

        If you don't want to use source filters - don't. Just don't go on a crusade claiming they are universally evil and people shouldn't put modules on CPAN that use source filters. CPAN is open for everyone - and that includes open for code that uses techniques you don't like.

        Perl --((8:>*
Re^2: When is it better to NOT release a new module?
by snowhare (Friar) on Nov 02, 2005 at 18:02 UTC

    You are right that it is a source code filter (albeit one that is portable all the way back to at least perl 5.005_04). But would you extend your remarks on why you believe that that of itself is a good reason to not release it? I have tried to deliberately create a syntax that cannot be easily 'triggered' by accident or mis-parse in a way that generates false line numbered errors. If a particular line in the original causes an error - that will be the line the compiler reports after processing as having generated the error. And a module has to intentionally use it - so it isn't like a random module will be "side-swiped" by it.

    So what, specifically, do you find objectionable about the use of source code filters?

Re^2: When is it better to NOT release a new module?
by pdcawley (Hermit) on Nov 08, 2005 at 15:22 UTC
    Your module appears to be a source code filter operating on general purpose perl. Such things should never be released. They're evil, nasty things and cause problems for other people.
    Tosh! If that were really the case, why is Perl 6 getting some seriously powerful tools for writing source filters? Source filters are hard to do well because general Perl is hard to parse, but that's a very long way from saying that they are evil and should never be released. Looking at the syntax shown in the module in question (and the performance figures claimed), I'd certainly be interested in using it in my own work.

      If that were really the case, why is Perl 6 getting some seriously powerful tools for writing source filters?

      Mu.

      They are evil in Perl5-land because they are, for all intents and purposes, impossible to make work reliably. They will be acceptable and accepted in Perl6-land because they’ll be easy to make work reliably.

      Personally, I’m far more excited about smoothly integrated macros than reliable source filters.

      Makeshifts last the longest.

      I rather expect the perl6 toolkit is more macro-like in intention and that's why its so cool. Of course I want the power of a source filter - its just that there's an acceptable implementation and unacceptable things like the OP suggested.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (6)
As of 2022-05-25 10:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (90 votes). Check out past polls.

    Notices?