[Catalyst] Modularity and its engineering tradeoffs

[Dominique Quatravaux]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel McBrearty wrote:

>
> Well, the accepted wisdom in both software and other fields of
> engineering has been there for a long time : use components, except
> where there is a *really* good reason not to.

Thank you for doing what it takes to chill the thread, I do appreciate
that. I agree with your statement, except maybe that I would remove
the stars around the word "really" :-)

> You might see your solution as being more simple, but I doubt that
> someone using your module would feel the same.

Depends on source-level documentation in that particular case. It's
not like the regex is 3 screenfuls long, which would indeed be bad.

>
> By the time you are using a framework like catalyst, you are not
> that likely to care about adding one more module either way.

I intend to use Alien::Dojo from outside Catalyst as well.

> And have you actually quantified this? Many modules are
> surprisingly small.

Matt did, I did not, and I am ashamed I didn't for it is now obvious
that my bloatiness argument was moot (see other part of the thread).

HOWEVER:

> I'd consider a reference to a module with a documented API than a
> regex. It's, erm, simpler. And the fact that it is a *component*
> makes it more trustworthy if you suspect a bug.

I don't fully agree with your view. Modularity does come with its own
set of software engineering costs, even if they are as well maintained
as a typical modern CPAN module:

    * module size: the bigger a module, the more likely it is to have
      bugs. I believe the KISS principle ultimately advocates against
      using a one-size-fits-all approach even if that means some
      limited duplication of efforts - and so does Perl, which IMHO
      heavily contributes to the success of the language among hackers
      (and the lack thereof in corporate circles, alas);
    * module age: old components typically have received much more
      scrutinity, especially a regex engine that is part of the core
      since ages and relies on an algorithmical foundation that is
      several decades old;
    * integration issues, where some upgrade in the supporting code
      (eg Perl's UTF-8 logic) causes bugs to materialize in the upper
      layers. This is perhaps best summarized as "bit rot";
    * and (I fully expect to be flamed about this) the infamous Not
      Invented Here (NIH) attitude *does* have its advantages,
      especially in a small team where having the framework author at
      hand to blame bugs on results in a shorter turnaround than
      waiting for the next round of bugfixes on CPAN! I have held this
      role for 5 years now in my shop and overall I think this has
      been positive to our business. Not by a wide margin though, and
      given Catalyst today as a starting point I would of course not
      go the same route again.

> I think a regex would be fine for a script that is only for your
> own use, or a throwaway tool. But for a module for public
> submission? It just doesn't make sense.

I cannot agree with that stance, as it ultimately means that Perl has
no edge in enterprise settlements with respect to "purer" languages
such as Python or Ruby. IMO the ability to go quick&dirty is also a
key part of Perl's power *including* in production use, as I argue
with Matt in another part of the thread. This point is perhaps better
made here:

http://xp.c2.com/YouArentGonnaNeedIt.html

(BTW c2.com is a really wonderful place for pondering about software
engineering issues)

Final note: I believe this thread is fully on topic for Catalyst,
because it tackles the way Catalyst itself is architected. In what
ways does Perl + Catalyst result in a better choice that Ruby + Rails?
Not because of the object model: as a successful Rubyist defendant of
some zealotry of mine pointed out, the inside of
Catalyst::Controller::BindLex is not exactly pretty. IMO, this has
something to do with the quick&dirtyness of Perl+CPAN, right there for
when you need it. I see beauty in this New Style of Perl: a
crystal-clear well thought-out cathedral of OO and modules, and the
occasional infamous kludge that cuts straight thru the problem at hand :-)

- --
Dominique QUATRAVAUX                           Ingénieur senior
01 44 42 00 08                                 IDEALX

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEfD56MJAKAU3mjcsRAiziAJwOmb9vc4/VU5YjDdIhRniH6iySrwCeOto3
N5pExiWkYHPgerSqrD6sx7k=
=bULO
-----END PGP SIGNATURE-----