Programmer Musings

Review of Higher Order Perl

Higher Order Perl
Mark Jason Dominus
Morgan Kaufmann, 2005

The simplest thing you can say about MJD's Higher Order Perl, is that it is not your ordinary, everyday programming book. It is not even your everyday Perl programming book. MJD introduces an approach to programming that will be new to most programmers. Even those who have some experience with these techniques will probably gain some insights and tricks.

Many of the techniques introduced in this book will be familiar to users of Lisp or Lisp-derived programming languages. If you haven't worked with one of these languages before, be prepared for an eye-opening approach to Perl and programming in general. If you have worked with one of those languages, you may be surprised to see the techniques that Perl supports.

The book begins with functional programming and recursion. This section gives the grounding you will need to understand the rest of the book. MJD goes on to explain programming with dispatch tables. Although I have been using dispatch tables for years, MJD still showed a couple of techniques that I haven't used. Next came caching, including memoization, and how caching can solve some problems with recursion. The book continues with iterators, streams, currying, parsing, and a large example of declarative programming.

MJD's style is clear and understandable. He gave the best explanation of currying, I've ever seen. He succeeds in showing how these techniques work and how you might use them to improve your own code. Possibly one of the most important points of the book is to show a different approach to solving problems with Perl. As he says in the Preface, many Perl programmers have been writing C programs in Perl for years. Part of the purpose of this book is to point out that there are other ways to solve programming problems. The more ways you have of looking at problems and solutions, the better your chance of solving the next problem.

My only complaint about the book was the long example used for declarative programming. Although this example tied together many of the techniques in the book, it did seem to drag for me. The example showed a declarative solution to a rather complex problem. As a result, it was easy to get lost in the details of implementation and lose sight of the principle being taught.

Overall, I would recommend this book highly to any intermediate or advanced Perl programmer. I am not a certain about recommending the book to a beginning Perl programmer, unless that person already has a background in multiple programming paradigms, including functional programming.

Operator Overloading and Naming

One of the things Java programmers seem to really like to hate in C++ is the concept of operator overloading. I have heard this from many Java programmers and seen it written by others. According to many, operator overloading makes C++ impossible to understand because you can't tell what a piece of code is doing just by looking at it.

When looking for this statement on-line, the first example I found was Joel Spolsky's article, Making Wrong Code Look Wrong - Joel on Software under the section A General Rule. I'll pick on Joel for two reasons here. The first is that the comment has very little to do with the topic of an extremely good article. Second, that I usually agree with Joel on the big things, but often disagree on smaller issues.

Joel uses the following example to prove his point:
i = j * 5;

He states, with complete conviction, that if you see that same snippet of code in C++, you don’t know anything. Nothing.

I believe that the operator overloading issue is a red herring. To prove this, I will transform the code a little.

assign( i, multiply( j, 5 ) );

This would be perfectly legal code in C++, Java, or a number of other common general purpose languages. I could easily define this code to do exactly the same as the original code when i and j are integers.

Now, when you see this snippet of code, what do you know? Even without operator overloading, you don't really know anything. If the programmer used good naming conventions, however, you could infer that j is multiplied by 5 where the multiplication is something appropriate for an object of j's type. You could further infer that the result of this operation is assigned to i using whatever conversions are appropriate for this assignment.

Furthermore, if we used a more object oriented syntax:

i.assign( j.multiply( 5 ) );

Although we now know that both i and j are object types, we still don't know any more than we did from the previous two examples. But, we still don't know what those methods do. For example, multiply could make a call to a relational database with the supplied parameter to give a string that i.assign() uses to make an HTTP request to a web server to update its current state.

If you found that this was the case, you would probably abuse the original programmer about using extremely bad naming. You probably wouldn't ban the use of the method names multiply and assign.

The issue, as I see it, is not that operator overloading is a problem. It's that some programmers name methods, variables, and/or classes badly. The fix is not to ban certain names, but to educate those programmers.

In my experience, most of the bad uses of operator overloading happen when programmers are new to the idea and they think it will be clever or cool to use an operator when a method name works better. Education and experience usually fixes that. (Others may have had different experiences, but that is what I saw.)

Maybe we should stop beating the operator overloading dead horse, and spend more time educating junior programmers about the importance of good names and the Principle of Least Surprise. In fact, the advice cited in Joel's article above is a good start for this kind of education.

Review of Perl Hacks

Perl Hacks
chromatic , Damian Conway, Curtis "Ovid" Poe
O'Reilly, 2006

When I first saw the title Perl Hacks, I was a little unclear what the book would cover. After all, the Perl Cookbook has recipes that span the spectrum from basic to advanced. What would Perl Hacks supply that wouldn't be found elsewhere?

The first few hacks answered those doubts superbly. The first 11 hacks focus on productivity in programming Perl. The first hack shows how to use Firefox shortcuts to make finding Perl module documentation easier. The next couple of hacks focus on getting more out of the Perl Docs. The section continues with ideas for using shell aliases, configuring Vim and Emacs for Perl, enforcing local style with Perl::Tidy, and running Perl tests within your editor. Although I had stumbled into a few of these or seen some of them elsewhere, these hacks were focused specifically on making you more productive, immediately.

The next few sections focus more on programming in Perl, including user interface issues, data manipulation, and module usage. The section on debugging covers several useful techniques. Some apply to any programming problem (binary searching for bugs), others are Perl specific (customizing the Perl debugger). The Developer Tricks and Know Thy Code sections will probably improve your Perl knowledge and skills in a number of ways.

The final section of the book should really push your Perl programming knowledge and skills. Most of the hacks in this section are pretty advanced. You may never need some of what is shown here. On the other hand, one of these hacks may be just the thing you need to solve the problem you are currently struggling with.

All in all, I was pleasantly surprised by Perl Hacks. Given the authors, I expected the book to cover interesting topics very well. I was initially concerned that the book might just be a rehash of information from other books, but that concern was quickly laid to rest. You may not learn something from every hack, but I'm confident that almost everyone will find something new in this book.

I definitely recommend this book to anyone programming in Perl, whether novice, expert, or anywhere in between.