Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc

by zork42 (Monk)
on Sep 08, 2013 at 05:48 UTC ( #1052876=note: print w/replies, xml ) Need Help??

in reply to How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc

Thank you everyone for your very interesting comments. :)

So in a production environment:
  • core perl modules: completely safe to use
  • non-core perl modules: research and judgement is required
  • Comment on Re: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc

Replies are listed 'Best First'.
Re^2: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc (source)
by tye (Sage) on Sep 09, 2013 at 02:31 UTC was a core module for a long time and was never at all appropriate for use in Production. But I agree that a module being in core makes it more likely to be appropriate for Production use.

    A module being "alpha" doesn't really mean that I should avoid using it in Production, IME. I also find it quite common for a module to have both some features that I would be comfortable using in Production and some that I would not.

    The most useful metric I've found for avoiding the use of modules in Production is ETOOMUCHMAGIC. An inordinate amount of complexity being relied upon to implement a relatively simple feature is a very bad sign, IME. As is the use of even relatively small amounts of non-mundane complexity.

    Non-mundane complexity (often found under the label "magic") is the worst kind because it leaks out in odd ways and interferes with other non-mundane complexity and often causes problems that don't appear at first, can be triggered or defused pretty much at random, and appear completely unrelated to their sources. You can waste huge amounts of time and effort trying to deal with such problems.

    While excessive depth of mundane complexity thwarts attempts at quick resolution by the sheer volume to be searched through and the great distance that can result between the problem and its source, which can make fixing the problem impractical.

    When deciding whether I want to use a module in Production or not, I usually read the source code. (Though, DBI is a good example of an exception to that; but it would take too long to try to properly explain that.)

    - tye        

      ... ETOOMUCHMAGIC ... Non-mundane ... smell

      Hmm, what's that mean?

      Re: Can an element be created because it was accessed ? ( || {} ); Yes, it sticks its fingers way too deep into guts...strong smell of ETOOMUCHMAGIC
      Practical example of "Is Perl code maintainable"
      Note that I didn't use File::stat because the BUGS section is unacceptable to me. ETOOMUCHMAGIC is such a common problem
      (tye)Re: Reading a pipe
      a bug in antique perl version, nothing interesting here
      Is Devel::Declare really so much less evil than source filters?
      said "weird issues that won't seem to make any sense". Those both smell very much like ETOOMUCHMAGIC.
      ETOOMUCHMAGIC breakage can be quite cryptic and fundamental and might not even hint at the module that is pumping in the most "magic". So you waste a lot of time trying to find the source(s) of the problem.
      Hello, three years have passed. What happened between D::D and the p5p? How did D::D evolve?
      Too much black magic
      Re^10: Scalar context of slice (vs grep)
      ETOOMUCHMAGIC -- assuming things that do not remain true -- an explanation given that included unnecessary complication and that complication also had the distinct disadvantage of having lead other people into problems -- quoted meme is seriously flawed
      using strict from another module
      I haven't used either, and I fear that you'll get bitten by ETOOMUCHMAGIC if you use them instead of simple templates --In addition to the Pod, I describe there's really very little magic involved in ToolSet
      Devel::Declare vs LISP like macros...
      Heh. Checking the reviews of one of the example modules, "Make sure that you have the latest Devel::Declare or you can have some weird issues that won't seem to make any sense". Exactly the type of error that result from source filters... ...The bane and hallmark of ETOOMUCHMAGIC.
      Use of wantarray Considered Harmful
      As for the several recommendations of Contextual::Return, I have to disagree. That module appears to have been implemented in a way that suffers significantly from ETOOMUCHMAGIC and I happily avoid it and encourage others to as well.
      Some thoughts around the "is Perl code maintainable" discussion
      Re^3: Your favorite objects NOT of the hashref phylum (inherit)
      I strongly dislike class-making frameworks that everyone and their dog wants to bolt onto the side of Perl. So I'm not going to be writing any plug-ins for one. I've never seen any significant value in any of them and most of them look quite prone to break things due to ETOOMUCHMAGIC (and I've seen several actually break things), so I'm quite happy to avoid all of them completely.
      Re: POD from code?
      create my data (not code) from POD ; Usually I find that approach to be a bit too much magic,
      removing someone elses AUTOLOAD
      PS I think I recall in Damian's PBP Dog book, he states AUTOLOADs are bad, and I agree! Too much magick.
      Re: Can't seem to use an AoH with Template::Toolkit
      In short, the problem is too much magic. When you call $cgi->Vars, you don't get a normal hashref. Instead
      Re: email pdf file - file damaged
      I have my reservations about IO::All, especially once you move from a hardcoded filename to anything variable because it reopens the security hole that was fixed by introducing the three argument form of open.
      but I would entirely stay away from IO::All for it heaps too much magic onto magic and relies on the undocumented assumptions made by Ingy.
      Re: Overloading print()
      operator Overloading can be very convenient, but too much magic can hurt maintainability.
      Re: WSDL generation for a SOAP::Lite server
      WSDL::Generator currently tries to use too much magic, and the resulting WSDL is not exactly easy to document.
      Re^6: RFC: Is there more to alias?
      You still misundestand how Data::Alias works, and you seem to see too much magic where there is none.
      Re^18: use fields; # damnit
      It just shouldn't be used on the application logic level too much magic is a nightmare.
      Re: Wanted: Spiffy evangelist
      Maybe the fact that nobody has voted on Spiffy yet could be a warning sign?
      To me, Spiffy is yet another way of being too clever for your own good. It is Ingys object framework, and it is mainly used for Spoon, which in turn is a nice thing for very small, very contained scripts and nothing else. I am wary of using modules that contain way too much magic, and if I were to build a bigger framework, I wouldn't rely on anything that requires a larger span of attention from Ingys part.
      WOW, ingy, author of Spiffy, is using Spiffy in modules he is writing/maintaining? You don't say /sarcasm
      Re: Your favourite gory detail...
      Using eof() with empty parentheses is very different...That's just too much magic for one parenthesis!
        Wow that's a lot of info there!
        It'll take me a while to go through that.

        What does "ETOOMUCHMAGIC" mean?
        "TOOMUCHMAGIC" presumably means, well, uh, "too much magic"
        But what does the "E" letter mean?!
Re^2: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc
by Anonymous Monk on Sep 08, 2013 at 06:33 UTC

    So in a meaningless-adjective environment: completely a meaningless-adjective to use or research and judgement is required

    I think research and judgement is required for everything because safe and production don't mean nothing :)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1052876]
[Lady_Aleena]: Well, not much of my code. A few little things people here like. The big things though, the more important to me code, people here seem to loathe.
[atcroft]: Lady_Aleena: My early code was pretty horrible... but somewhere early on I learned not to take criticism of my code personally... which was probably a good thing, considering the kind of code I wrote at the time. :\
[Lady_Aleena]: I am hungry, so I'm going to go make something to eat. I hope you figure it out atcroft. Have a nice night!
[atcroft]: I have one script that I have started re-writing several times over the years, and have yet to get it working in a cleaner/better form. (It is some smelly code-I did not even know about hashes at the time I wrote it.)
[atcroft]: Enjoy, Lady_Aleena!

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2017-05-27 05:27 GMT
Find Nodes?
    Voting Booth?