<intro>
I know that Duff's device in perl has already been discussed here and most probably elsewhere. In particular a Super Search turned out the following threads:

Basically they all discuss the perl version/translation of the actual Duff's device logic. But I'm asking something different.
</intro>

Specifically I'm asking about highly bummed perl code, that one has felt the need to write instead of a less obscure version. Indeed there would be tons of obfu and golf code to exhibit - but I'm not talking about stuff done for fun. I'm rather focusing on so called "production code" in which one has felt for whatever reson the need to leave obscure code spotting an intricate and maybe surprising perl feature, probably along with a big comment indicating both what he/she is doing and why he is doing it that way.

So, do you have a favourite code portion of yours that you would regard as your own perlsonal equivalent of Duff's device?

Note: in case you wonder and before you point it out... since this has directly or indirectly to do with some sort of optimisation: yes, I know that "premature optimisation is the root of all evil", and I'm asking just out of curiosity!

Update: to partially answer to myself, I was thinking about something along the lines of this example of mine, and check in particular merlyn's comment, which IMHO makes it appropriate for this discussion. But I bet there must be something more akin to the abstract essence of "Duff's device"...

Replies are listed 'Best First'.
Re: Perl's own Duff's device?
by Zaxo (Archbishop) on Dec 22, 2005 at 16:41 UTC

    I think that the reference trick for CGI.pm's html generators would qualify. For example, 

    use CGI ':standard';
my @foo = qw/foo bar baz/;

print p({}, @foo), $/;
print p({}, \@foo), $/;

__END__
<p>foo bar baz</p>
<p>foo</p> <p>bar</p> <p>baz</p>

    [download]
    That's pretty puzzling to somebody who doesn't know that CGI.pm convention. Very useful if you have to build a table on the fly.

    The need for that has pretty much disappeared with the adoption of powerful Template mechanisms.

    After Compline,
    Zaxo

[reply]
[d/l]

      Well, that's interesting and... I didn't know about it! It may be certainly useful for quick hacks...

      Actually it may make some code of mine which massively uses the shortcut functions even simpler/cleaner.

[reply]
We call it "XS"
by Anonymous Monk on Dec 22, 2005 at 20:06 UTC
    Note: in case you wonder and before you point it out... since this has directly or indirectly to do with some sort of optimisation: yes, I know that "premature optimisation is the root of all evil", and I'm asking just out of curiosity!

    It's called "XS". :-) It's hard to understand, has a bunch of odd little rules and quirks, and makes the relevent perl function typically run several times faster than the more straightforward encoding.

    It's also a right pain to debug and maintain, again, like Duff's device, and other assorted hackery and trickery. ;-)

    --
    Ytrew

[reply]
      Good point, although... may I recommend you to put an indication about the old subject when changing it in a reply? This has been discussed here several times. There are good reasons to do so, mostly related to searching: having been bashed myself, and explained why, now I stick to this "rule" whenever I really feel the need to change it, which happens quite rarely, in fact.
[reply]
Re: Perl's own Duff's device?
by choedebeck (Beadle) on Dec 22, 2005 at 16:23 UTC
    Personally I am of the opinon that if there a a clear consise way to do something, then it should be done that way unless there is a really good reason for make it complicated and I think that most people would agree with me.

    Code quality naturally degrades the more people modify it. I don't see any reason to contribute to that by intentionally writing complicated code.
[reply]

      I agree with you, do not misunderstand me! It all boils down to what you mean by "complicated". For example there may be a very concise way to do something that would also be fast, but may end up being unclear except possibly for very expert programmers and that the "simpler" solutions may all end up being... ehm... more complicated!

      Indeed I was specifically asking about personal experiences with situations in which there were "really good reasons to make it complicated", because I don't recall any in my own experience, but others may well have! Just being curious, you know...

[reply]

Back to Meditations