If you aren't Happy
Which Dwarf Are You?

Dear John. Please arrange for Adobe to implement the following feature for me. I love the "Visualize Spots" checkbox in the LightRoom / Camera Raw "Healing Brush" as a way to locate dust spots that need to be cleaned away. The problem is, you need to be zoomed in at 100% to effectively deal with sensor dust, and sometimes it's not clear whether a particular mark on the screen is a fault or a feature. Then you need to click to normal view, and back to the edge-detection view. It's a problem having to move the cursor down to the checkbox, back to the spot to clean away, and back to the checkbox. A key-chord combination to enable and disable the edge-detected view would be a great benefit ... and there are so many to choose from! It could be Ctrl-H, since it's a Hide operation; or like overflow/underflow indication, it could simply use the control key. Only while healing, you understand. That's all right, no royalties are necessary. Tom 16 J...

Is there something that irritates you about Perl? One little thing you wish you could change, to make life so much easier? For me, it's the way declarations work. Whether it's with local, our or my, you can declare a variable name, or a list of several variable names: my ($x, $y, $z); Of course, you can initaliaze variables as you declare them. my $bank_balance = -999_999; my ( $x, $y, $z ) = ( 0, 0, 0 ); But if you have a number of variables to declare, and they aren't directly related to each other, as (x, y, z) clearly are, it would be so much better to declare the variable and immediately assign a value to it on the same line, the way C, Javascript and numerous sensible langages do. Currently, 'my', 'our' and 'local' expect a variable name, or a list of mariable names. So one possibility would be to provide an alternative form which takes a hash. Ideally, values defined in one line could be used lower down. my { $sides => 3, ...

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...

I've been looking at the module perl5i , which puts a sideways twist on Perl, eliminating tons of boring boilerplate, and introduce many conveniences. In this case, the i eliminates complexity. Installing perl5i installs a number of other modules as well, on the other hand life becomes better once they are installed. If you don't have cpanm or one of the other improved CPAN installers, the simplest way is to install perl5i and its friends using the command       sudo cpan perl5i You may need to type in yes to have cpan  install dependencies. Some modules are needed only temporarily during installation, and you are asked whether you want them permanently installed. Perl modules don't take up very much space, so I always go for it. Installation is a bit different on Windows or Linux machines, but you can figure it out, you're a mighty Perl programmer! One consideration is that major versions of perl5i may change in drastic ways. But you don't include p...

I presented this challenge at work as a beat-the-winter-blahs activity. But then I felt I couldn't present a merely operative solution. As the local Perl geek, I felt required to demonstrate that Perl could do clean, well written solutions, not just line noise. I wanted a balance between advanced Perl features and easy comprehension. On the Unix command line, I prefer piping commands together, rather than using a bunch of intermediate files. Similarly in Perl I advocate using map{} and grep{}, and feeding the output of one function into the input of another. I consider those standard idioms any programmer needs to learn. On the other hand, there were a couple of situations where exceptions and oddities in the code made me uncomfortable. Pulling things into subroutines such as calc_field_width() simplified things and made the code clearer, I think. I guess the lesson of that is that short subroutines are better. I knew that! I'm open to suggestions for alternative ways of...