in reply to Re^7: Data Structures
in thread Data Structures

If I should follow your reasoning, I should forego the use of modules such as DBI, CGI, List::Utils, ... for the simple reason that one looses control by using other people's modules, especially when they are fairly complex and might hide dragons behind their nice APIs, and because it is faster and more memory efficient to program directly to the bare metal.

That's the second time you've used this specious argument. I ignored it the first time but this time I'm going to respond.

  1. DBI.

    A function rich interface for sure, but look at the complexities it is covering up. Every RDBMS going, and all their disperate variations and proprietary features. The result, as complex as it is, is far simpler than any one of the C interfaces it wraps. And far, far simpler than their combined interfaces. Ie. It is a simplification of the many things it encapsulates. (The quoting facility alone is worth its weight. Have you ever read the rules for escaping SQL binary data?).

    And take a look at its dependancy list. Three (all core) modules and one for testing (also core).

  2. CGI

    A bit heavy--mixing the HTML generation stuff in with the CGI stuff is generally seen as not such a good design. Especially as they are also generally eshewed in favour of templating.

    Its dependancy list? One core module.

    But overall, it has stood the test of time and is still actively and responsively maintained. It even caters to both the OO and procedural interfaces.

    I usually opt for CGI::Simple on those (rare) occasions when I do CGI work. But note that it unashamedly derives both its interface and most of its code from CGI. It just omits those parts that most people don't use anyway.

  3. List::Util (no 's'), is my most used module.

    If you supersearch you'll find one of my posts in thread a entitled something like "Your most used modules are?" where I state as much.

    Search a little deeper and you'll find one that says something like: "Is there any program in which List::Util isn't useful?".

    I think reduce should be a part of the language as it will be in Perl 6. But that wouldn't prevent me from using List::Util. Nor having it preloaded into my REPL or as a standard part of my Perl template along with strict, warnings and Data::Dump.

So I'm not anti-modules, nor anti-CPAN. And neither charge will stick no matter how hard you push it.

I'm not even anti-Moose. It is without any doubt the very best of the OO modules around. And (if it ever compiles for Win32), whenever I have an application for a module that will benefit from OO, I will seriously consider using Moose. This exercise caused me to look deep into the guts of the beast and I am seriously impressed by both what it does and the way it does it.

I'm less impressed with some of the dependancies and the choice to use them. A couple of modules (IMO) substitue a module, a use line and a complicated line of code (in the calling program, and a lots of often unnecessary code in the module itself) for a rather simpler, single line of core perl code.

But for the OPs application, or at least those details we are informed of, the use of OO doesn't simplify through encapsulation. It complicates through encapsulation. Structs as objects is an abuse of OO. Indeed, if I remember correctly, there is a quote from theDamian (Author of Object Oriented Perl) where he lists a few examples of when not to use Object Orientation. I believe that this application (wrapping core functionality without value-add) would fit quite neatly into two (or even three) of his categories.

Sure your approach uses less memory, but I don't get an out-of-memory error and yes it is faster, but I don't mind if it runs 20 seconds or even two minutes. I find the Moose aproach easy and clear. Its declarative-like syntax is self-documenting. Yes, in six month's time I will have to look-up the docs again to see what the accessors are called, but do you really think I will remember in six month's time that the line-date is the first level of the hash and the station data is the second level of the hash and the Easting, ... is in an array rather than a hash, which are indexed by constants?

As I said above, for this application, the performance (memory or cpu) doesn't matter a jot. If there were 100,000 or a million lines it might, but that's unlikely given what the data represents. Much more significant is the weight of the documentation. For the module I offered (as offered) there are 25 lines to read. And 30 seconds picks out one line that tells you all you need to know about the data-structure.

Contrast that with facing the problem of refamiliarisation with Moose's 20+ modules and reams of documentation six months from now. Which do you think will be easier to understand?

I think we just have to agree to disagree.

Fair enough. But if this discussion serves to cause you, or anyone who read it, to think twice about wrapping core facilities in complicated and heavyweight wrappers (OO or otherwise), then it will have served good purpose.

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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^9: Data Structures
by stvn (Monsignor) on May 07, 2008 at 15:53 UTC
    I'm not even anti-Moose. It is without any doubt the very best of the OO modules around.

    Wait, your confusing me now :P

    And (if it ever compiles for Win32), ...

    The guys over at Best Practical are trying to replace all my XS usage with Pure Perl alternatives, so that may happen soon. Although I have to wonder if you have tried it on Strawberry Perl yet? I have heard of some people having success with that (we currently have a broken test on windows, but its the test, not Moose).

    ... whenever I have an application for a module that will benefit from OO, I will seriously consider using Moose.

    Oh, please do, I would love to convert you :)

    This exercise caused me to look deep into the guts of the beast and I am seriously impressed by both what it does and the way it does it.

    <being_serious>Thanks, that actually means something coming from you given the depth to which you tend to analyze and look at stuff</being_serious>. Be careful though, Moose-guts tend to stain and are really smelly if you leave them out for too long.

    I'm less impressed with some of the dependancies and the choice to use them. A couple of modules (IMO) substitue a module, a use line and a complicated line of code (in the calling program, and a lots of often unnecessary code in the module itself) for a rather simpler, single line of core perl code.

    Could you be more specific as to what you mean? I would happily remove a dependency if the replacement were as simple as that.

    Contrast that with facing the problem of refamiliarisation with Moose's 20+ modules and reams of documentation six months from now.

    FWIW, to use Moose, you really just need to read the Moose::Cookbook, and the POD of Moose (maybe a little in Class::MOP::Class and Class::MOP::Attribute too, but we are gonna move the relevant bits up to Moose soon). If you want to use roles, then you need to skim the POD of Moose::Role too, but you will find it is very similar to what is in Moose. If you want to use types, you need to read the POD for Moose::Util::TypeConstraints. Everything else (especially everything in Moose::Meta::*) is optional, unless you want to dig into the MOP, in which case your needs are becoming quite complex and so you should expect to have to read 20+ modules worth of docs (and maybe even a book or two) to use it properly.

    -stvn
[reply]
      Wait, your confusing me now :P

      :) I'll take it that this is now redundant. My objections are not "whether" OO or Moose are useful, powerful desirable. Just when.

      And the 'bugs' I alluded to were purely hypothetical. The point being that as systems become more complex, the costs of managing and negotiating between the sub-component authors grows exponentially. Users of complex systems have to take that into account when deciding if the benefits of re-use of those complex systems outweigh the costs to them. Including when things go wrong inside those systems.

      If a users application requires, and will benefit from, a large proportion of the features--code generation, introspection, etc.--that Moose provides in buckets, then it's a no-brainer to stand on the shoulders of those that write and maintain that complex, powerful and well-designed system, rather than starting from scratch.

      For the OPs application, as described, I do not think those criteria are met.

      The guys over at Best Practical are trying to replace all my XS usage with Pure Perl alternatives,

      Whilst I think that Pure Perl alternatives have some merit, I also think that the (further) performance hit of removing all the XS code from Moose would be a mistake. Most XS code will compile on Win32/AS, with only minor changes. The difficulty is in locating them.

      Oh, please do, I would love to convert you :)

      I don't need converting to the benefits of OO--used appropriately. As far as Moose is concerned, I'm already convinced that is is "best of breed" for projects requiring its featured. Far better than most everything else in the Class::* and Object::* name-spaces.

      Could you be more specific as to what you mean? I would happily remove a dependency if the replacement were as simple as that.

      It's not just about simple substitution. It also about choosing to use some of them.

      • Sub::Uplevel

        From the Caveats:

        Well, the bad news is uplevel() is about 5 times slower than a normal function call. XS implementation anyone?

        Perl's function calls are already slow. Moose places (of necessity for its function) many extra layers of function call over raw access. Rather than adding another layer, who's only purpose is to deceive, it would far better (for everyone) to give full traceback (ala Carp cluck/croak)), than to impose the performance & misinformation penalties of "hiding the truth".

      • Sub::Exporter. a sophisticated exporter for custom-built routines.

        There's a lot going on inside this module. That's a result of the power of the features it can provide.

        The question is: Is Moose using or benefiting from that power? Would Exporter or Exporter::Lite, or even just a custom import() serve Moose equally well for its needs, and avoid some of the overhead?

      • Sub::Name -(re-)names a subroutine.

        What does return subname 'Moose::Role::extends' => sub {... }; buy you that

        *Moose::Role::extends = sub{ ... }; (or even: sub Moose::Role::extends {...} doesn't?

        (I think I may understand the reasoning behind not using the latter, but better that you decide one way or another yourself

      FWIW, to use Moose, you really just need to read...

      Sophisticated systems require a good deal of good documentation. My comments were simply to defuse the notion that use of accessors/getters simplifies maintenance of nested, built-in data-structures.

      The question here is: do you need or benefit from the sophisticated system (for your specific application)?.

      For this application, loose wrappings around built-in data-types, my conclusion is no. That in no way detracts from Moose when used for that for which it is intended.

      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.
[reply]
[d/l]
[select]

        Sorry, been meaning to respond for a while, but been busy. I do agree with you that if OO is not appropriate, then don't use OO. I have been a huge fan of functional programming for a while, and honestly if I could use OCaml/LISP/Scheme/etc for $work, I would, but there is basically no decent libraries and lots of academic "abandonware". That said I am also not a big fan of YAGNI, and since at $work we typically maintain our apps as well as write them, I prefer to treat even small projects as if they might grow large (which they typically do, at least for us). But anyway, this is all a matter of style and environment. So let me just address the dependencies you listed.

        Sub::Uplevel

        This is not my dependency, but a dependency for Test::Exception, which I consider a key part of any good testing toolbox. So that one is not going anywhere unless the Test::Exception author removes it. Moose does not ever use it itself.

        Sub::Exporter

        Well to start with, Exporter is gotta be the biggest piece of bloatware in the perl core modules. I hate that module with a passion, just thinking about how bad it is makes my skin crawl. I never cared for Exporter::Lite either, it is better, but really the @EXPORTS and @EXPORTS_OK stuff is that makes me stay away, I don't like having to make public variables to export stuff.

        Sub::Exporter on the other hand is awesome. Not only is just for exporting subs (who the hell exports variables anymore really), but it can do all sorts of fun tricks. You couldn't do this with Exporter: 

        package LOL::Cat;
use Moose 'has' => { -as => 'i_can_haz' };

i_can_haz 'cheeseburger' => (
    is      => 'rw',
    trigger => sub { print "NOM NOM" }
);

LOL::Cat->new->cheeseburger('KTHNXBYE');;

        [download]
        Really, I think Nuff said there :P

        Sub::Name

        Well first let me say that we have made this dependency entirely optional now as part of the whole "make XS optional" thing that the Best Practical people asked for.

        What does return subname 'Moose::Role::extends' => sub {... }; buy you that *Moose::Role::extends = sub{ ... };
        To start with the CV will still have the name "__ANON__" and will not seem to come from the "Moose::Role" package (unless you did that code within the Moose::Role package itself). I think that it is important to maintain this internal consistency when building classes. But anyway, it's optional now so you can skip it.

        -stvn
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom