If you aren't Happy
Which Dwarf Are You?

I was somewhat uncomfortable that my solution to the combinatorics task, which involved a single, not very long routine, became so long with the addition of command line processing and POD  documentation. For one thing, while it had some information about how to invoke the routine, it did not have tests. I still feel that a book on programming, say, should have a fully-implemented solution once a chapter, perhaps, to show the way things should be done. But that is too long for every single bit of code. Full documentation and sample implementations stretch on too long, compared to the few lines a snippet actually deserves. Providing tests may still be appropriate. They take up less space than full documentation, yet explain how the various components work, by the very act of stress-testing those lines of code. Tests provide examples of how the code should be invoked. Revising the combinatorics task into a module, this generates: use perl5i::2; # ---------------------------...

I've long admired the way functional languages specify multiple implementations of a routine for different sets of argument values, to detect terminal conditions. Converting a Perl6 solution  of a combinatorics task to Perl5i, I realized the plain Perl solution isn't necessarily all that bad, either. The problem is to list the different ways you can select M elements from a set of N. Select 2 elements from a set of 4 would lead to the values ( 1, 2 ); ( 1, 3 ); ( 1, 4 ); ( 2, 3 ); ( 2, 4 ); ( 3, 4 ). Oh yeah, they want the characters in each combination in sorted order, and  the list of combinations sorted, too. So it all consists of a single routine which gets invoked as combine(3, ['a'..'e']) . Ignore the first couple of lines, for a moment. If the first character of the set exists in a combination, it must be in the first position, since the characters are in sorted order. That means the remainder of the combination must be one character shorter, made...

Continuing the exploration of Perl5i beyond  part one , I decided to treat perl5i as a language and use it to implement tasks at  Rosetta Code . Since Moose is a complete OO solution, I use a lightweight approach to OO, where used. The first RC task I implemented is 100 doors : see  the full implementation. In terms of documentation, I gave each routine a small header in which I show how the routine is invoked, specify the inputs and outputs, and summarize the primary actions of the routine. Since the task is defined in terms of a number of doors, and operations on those doors, it seemed appropriate to use an object. "some object" + "operations on that object" ==> "segregate into an OO implementation". I used a simple constructor with initialization performed in _init() to simplify subclassing. The constructor doesn't need to be modified, just a new _init() written to handle additional attributes or arguments, if any. The new implementa...