After more than a day, it appears that the blog author might never approve my reply to his reply. So I'll just post it here:

> > It is the bane and hallmark of ETOOMUCHMAGIC

> Actually, all of this is the bane and hallmark of EXPERIMENTAL. We're a small group of people.

Ordinary bugs are the bane and hallmark of new work.

"some weird issues that won't seem to make any sense" is the bane and hallmark of ETOOMUCHMAGIC.

The great difficulty in giving good errors in the case of failure is indeed another reason why I avoid complex magic.

And I've posted it to this part of the thread because stvn said:

In this case I suspect that the comment speaks less to the overall fragility of Devel::Declare, and more to the fact that Devel::Declare is still a new module and still needs to have all its bugs worked out.

I wasn't complaining because the module (horror!) had a bug at some point. I was noting that the description of the bug was quite telling. It sounded exactly like the complaints that come in when people are using Switch.pm. I don't hear things described that way other than when too much magic is being invoked. And I don't believe the blog author really refuted that characterization.

The blog author admitted that when things go wrong (people will make mistakes, even when using Devel::Declare) the resulting error message may be not "decent". The (likely more honest) CPAN review said "weird issues that won't seem to make any sense". Those both smell very much like ETOOMUCHMAGIC.

And I wasn't really even talking about "fragility". ETOOMUCHMAGIC doesn't always make things "fragile" as in "easily or frequently broken", though that can certainly be one of the unfortunate consequences. The more characteristic problem with ETOOMUCHMAGIC is that when it does break something, the 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. Understanding the failure very often is extremely complex. And fixing the problem very often ends up being very impractical (because the breakage is fundamental to some deep aspect of the complex magic that is hiding behind the "subtle" exposed interface).

About a year ago, I was mentoring somebody who came to me with a very strange Perl failure. They were implementing some testing tools that actually made use of quite a few different pieces of magic. I was pretty firm in pushing them away from some forms of magic that I considered too problematic or just very much not worth the benefit (and I found I had to keep repeating these pushes because this developer really did want to solve problems thoroughly).

Anyway, the failure provided very few clues as to a likely culprit. I told him to replace the XS-based JSON library with a Perl-only equivalent. He pointed out that the failure was happening in parts of the code that weren't using JSON and weren't even "close to" the parts that were using JSON. I told him to humor me. The problem went away when he replaced the JSON module.

I was quite busy with other tasks at the time and so did no diving into the problem and would not have looked forward to such a dive. It looked to me like such a dive would have taken a lot of time and concentration and knowledge and then might not have been successful in actually identifying a problem much less finding a fix for it.

My instinct of "remove the most magic piece" served me well that time (it often does). Luckily, this particular project was young and it was easy to rip out that piece. Relying on subtle magic is a recipe for pain, IME.

By the way, as I noted, this testing tool required quite a few pieces of magic. So many pieces that I would never consider it an acceptable tool in a Production environment. I pushed hard to completely avoid the heavier magics being considered and to make even the moderately interesting magics optional (and part of the motivation for creating this tool was that the existing "state of the art" tool was unconditional in its use of some fairly mild-sounding magic that often isn't needed and that people had complained about having problems with). I think the tool will be invaluable in a testing environment (I changed jobs after that and haven't yet had a chance to put it to good use). And I'm also quite sure that some of the magics used will cause problems in some situations.

I use magic. But I'm pretty strict about avoiding building things on top of magic. It is experience that led me to such caution. Now I always look for the warning signs of magic.

Let me start out by saying that I personally do not use Devel::Declare or any of the modules which use it (MooseX::Declare, TryCatch, etc). My reasons for not using it are pretty much the same as your reasons. To be specific, I think that MooseX::Declare pukes up too many internal details when it errors and this makes for very tricky debugging and fixing that seems to be a non-trivial task (I say this only because no one seems to have fixed it yet or even come close).

This too is exactly why MooseX::Declare remains a MooseX:: module and is in no way an "official" part of Moose. Not until I am sufficiently convinced of the stability of Devel::Declare and the error messages of MooseX::Declare greatly improve will it even be considered.

In short, I totally agree with you (horror!), magic should be used sparingly and is never a foundation upon which you should build.

But, all that said, the Devel::Declare team is trying to reduce the magic-ness by working with the p5p folks. What will come of this? I have no idea, we will have to wait and see.

-stvn

pukes up too many internal details when it errors and this makes for very tricky debugging and fixing that seems to be a non-trivial task

sometimes I still have this feeling about Moose.

Hello, three years have passed. What happened between D::D and the p5p? How did D::D evolve?