Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • It's in a very functional style, that's all.

    True, most Perl programmers would have trouble maintaining it, and this is a valid concern.

    Maybe you should comment it heavily and stare at it until you understand it forward and backwards. There's a lot to be gained by functional programming. Generally, the fewer the intermediate variables and the less the code, the _better_ the maintenance in the long run.

    Obnoxious comment. Could you make it even more functionally gnarly with something like this (untested)

    • Aack! I'll pretend you didn't write that :)

      One of the reasons why I break things into smaller steps like I did is that it's easier to insert debugging statements. As for the above, I wound up using an entirely different strategy suggested by Gav.

      sub _set_up_names {
          my ($self,$products) = @_;
          my $length = 0;
          my @names =
              map {
                  local $_ = [$_->id, [split ' ', $_->name]];
           

      • I've heard this argument about inserting debug statements, but I think it's oversold.

        If I have something in an extreme functional style and I need to debug it, I just replace one of the function calls with a call to a function_debug wrapper. In my above extremely functional style, you could add map_debugs or mapcaru_debugs which would print arguments and then apply the map or mapcaru function.

        One added advantage of this is that you can get all your maps or mapcarus to confess at once, often yielding unexpected insight.

        However, I do think that turning Perl on it's head to look like Lisp is probably not a good idea. As I alluded to above, maintainability is a good argument against this sort of thing. It is pretty arrogant to assume that everyone will be in love with your own odd taste for functional style.

        OTOH, I do spend a lot of time correcting annoying bugs with interim variables, like I might use $name for $names in your above example. Sure, this is quickly found, but it's annoying and you can stare at it for a few minutes wondering what you've done wrong.

        When I write in a functional style, I sometimes feel that there are fewer things that can go wrong. But, I'm not sure.

        The short functional solutions sometimes just feels so elegant, but that's a personal taste thing.