Slashdot Mirror
Randal Schwartz's Perls of Wisdom
Perls of Wisdom is a collection of 65 selected columns from Linux Magazine, Unix Review, and the now-defunct Web Techniques magazines, written between May 1995 and July 2004. In each column, Randal discusses some problem that he had to solve, or that someone else needed help in solving. He carefully discusses the problem, and then shows the Perl code needed to resolve it. Many of the columns are complete applications that can be run (with minor modifications) by the reader. (The listings are also available from the apress.com web site.) Each column has been reproduced as it was written in the original magazine, with "Randal's Note" prepended. Therein lies this book's best feature and greatest flaw. Allow me to explain.
When I first picked up this book, I had only read a couple of Randal's columns (from Web Techniques), and saw that he wrote tutorials of proper Perl usage. He also relies on the wealth of modules submitted to CPAN to leverage a solution. After all, why reinvent the wheel? I expected to see more commentary on the reasons behind choosing one solution over another, or insights into the inner workings of Perl itself. I more or less got what I expected. For example, the first column reproduced in the book (It's All About Context) explains why, when someone used my ($f) = 'fortune'; instead of my $f = 'fortune'; he got in trouble with the law (see the book to understand the legal issue). The first form only retrieves the first line of the output of the fortune program, while the second form retrieves the entire output. Little items such as scalar versus list context can trip many Perl coders.
The first chapter (Advanced Perl Techniques) does give you many tips and insights like the example I just gave. All but two of the twenty columns are little tutorials on the ins and outs of handling the commonplace day-to-day issues that Perl can address with ease. Some delve into more obscure topics, such as the difference between shallow and deep copies of structures, and Perl's Taint mode. Two columns contain complete programs. One extracts the text from the man pages and determines their "fog" index (a measure of readability). The other creates a mirror of files needed by CPAN.pm to install new modules. For each program, Randal gives the entire listing as well as an almost line-by-line description of how it works. Each column is written in a conversational style that is easy to read, yet doesn't talk down to you.
The following chapter is comprised of seven tutorials on the various aspects of searching, sorting, and formatting text. In addition to describing the creation and compilation of regular expressions, Randal also discusses formatting and the nifty "Schwartzian Transform" (Perl's map-sort-map idiom for sorting on almost anything) which was named for him, but not by him. While some of the information is a little long-in-the-tooth (the column on Text-Processing was written shortly after Perl 5 was released), it's all interesting and educational nonetheless.
Chapter 3 starts refocusing the use of Perl to web sites. This chapter discusses HTML and XML processing in six little columns. He shows how to generate a web page index, producing a web page calendar from a file of events, and parsing XML to retrieve the data within. He also includes a lesson on how to use Perl to compare two arrays to create an HTML-formatted difference table.
The next chapter demonstrates that Randal has spent a lot of time working out ways to update and improve his web site. It covers the intricacies of CGI programming in Perl. All but one of the fifteen columns are complete programs (again, available from apress.com) with line-by-line commentary. The programs do implement mostly worthwhile functionality, but each column was pretty much "I had this problem, so I wrote this program. Lines 1-3 do this; lines 4-5 do that, etc." Granted, some of the programs are pretty nifty (check out how he automatically keeps track of the "What's New?" pages), but the reading of one program after another started to become stale.
The final chapter is titled "The Webmaster's Toolkit," consisting of fourteen programs and three tutorials. Randal covers diverse web server background topics such as creating a light-weight load balancer, random links, and forcing users to enter through the "front door." There are also instructive techniques for throttling your web server's usage of the processor (a necessity at the time for Randal, as his web site was co-resident on a server with others), and calculating download times.
In its entirety, Perls of Wisdom contains 65 columns, split roughly half-and-half between tutorials and fully commented programs. More than half of the columns show that Randal uses Perl for web processing more than for general scripting, data reduction and reporting. His tutorial articles are top-notch, but I have a quibble over his program articles, which are somewhat dated. There were a number of prefaced notes to the effect that today he'd do it differently with some new feature or CPAN module. I really wish he had actually updated the column to show the new coding techniques. The original code is interesting in the historical sense, but I wanted to see nuggets of Perl wisdom for me to use in my daily job. The writing style is fine; the bits of insight are useful, but many of the programs are too specific to problems you or I may never see, and were solved in code that's showing its age. I'm glad I got to read the book, but I think it only rates a 7 out of 10.
You can purchase Randal Schwartz's Perls of Wisdom from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I used to do small scripts in perl and I originated a fairly complex system in Perl which was written as if it was C++ (no direct access of object values, only methods, etc).
However having said that, I also later inherited a system written in Perl. Thousands of lines, lots of complex data structures. This experience permanently soured me on Perl. While it is possible to write good code in Perl, this doesn't always happen. Especially with the sense that perl is a scripting language that you use to develop hacks or short scripts. The temptation to do a shortcut is too great.
This leads me to another annoyance: Magic. Perl is too magical. To be truly effective in Perl you must know most or all of the magic. If you are unfamiliar with an idiom you have to resort to the manual/books. This means there is not a simple guiding principle (ie: abstraction) you can take and apply to problem solve any situation. The movement to exceptional magical cases is backwards thinking.
None of this matters if you're sitting at home writing one-off cgi-scripts (which is how perl became most famous), but once you move into the area of "professional" development, or at least large scale coordination, you quickly see the value in simple readable code.
In the end, most people who get paid to write code are rewriting and enhancing existing code. If it takes a week to understand a 500 line perl script, the code has probably delivered negative value to your team and company!
A good programmer will write readable code in any language he's writing in.
The world does not break down into three distinct camps: "Non-programmers", "Good programmers" and "bad programmers". Actually there is a spectrum and all programmers live somewhere along it. A language can encourage readability or discourage it. What does Perl do?
The TIMTOWTDI ethos is ultimately what makes the language as useful as it is. The more ways there are to do things, the more things you can do with a little creativity.
I'm sorry, one does not follow from the other at all. If I added a "+++" operator to C that increments by two then I now have at least three (obvious) ways to increment by two. Does that mean that I can now be more creative in C?
The myth that all Perl code is unreadable is preposterous.
Nobody claimed that in this thread.
I've written several very complex pieces of code in Perl that are not any more difficult to comprehend than any piece of C code designed to do the same thing, and often much less so.
Strange that you use C as your benchmark. How about a language designed in the last twenty years with readability as a goal? Perhaps Java, Python, Ruby, O'Caml, Haskell, etc.
I agree with everything you say, though some languages make writing read-only code easier than others. APL comes to mind immediately. I did not intend to convey the fact that Perl was unreadable. Rather I feel that Perl gives you more rope to write unreadable code than other languages, like Python.
Of course you can write some incredibly terse code in Python too, especially with recent language additions.
And I would not include C in a list of languages for writing readable code in.
I completely understand your point and can even agree to a certain degree. I think what most people fail to understand about Perl's appeal is that most of the structures in Perl that drive some programmers nuts are ideas that are borrowed from natural languages and aren't found often in other programming languages.
If you think about the idosyncracies in English (or any natural language), it's really a miracle that we can communicate with each other at all, and Perl's adoption of context and implied default variables is very similar to methods used in natural languages to make communication more succinct.
And therein lies its appeal for some people. It's a language that you can just write, much the same way that you would write a paragraph or sentence. Most programming languages are highly structured complex sets of instructions. Perl is an actual language, and writing Perl feels more like writing English (once you become literate in the language that is).
I think Perl appeals to hackers who like to write. I think Perl flexes some of the same mental muscles that writing and speaking flex and therefore appeals to people who tend to think in language-centric ways. It also probably explains why the primary strength of this idiosyncratic, language-like programming tool is processing text and text-like patterns. It just appeals to people who are linguistically minded and was developed with language interpretation in mind.
That doesn't make it good or bad IMHO. It just makes it one way to approach the problem of programming. We're always talking about ways to make programming better. Using graphical tools and other advanced CASE tools to make it less like writing assembly code and more like writing a real language or doing some other non-technical task that we're already used to. Perl is an example of one way to accomplish that goal.
It appeals to a certain mindset so it's obviously not for everyone, but that's what happens when you try new things (though I guess you could hardly call Perl new anymore). Same thing with LISP, it's a really really advanced high level language, but a large number of programmers hate it despite its power and advantages. It approaches the programming problem from a different angle and provides a unique solution that some people like and others just plain don't.
I personally wish there were more languages like Perl and LISP to be honest. They're not always the most practical for all situations and I certainly wouldn't write every of my applications in either language, but they show us that's there more to programming than just C-like syntax and pointer arithmetic. And sometimes, really good ideas do come out of the fruit loop languages and find their way into other development tools.
It is not that Perl is by nature less readable, however its community promotes values of terseness over readablility. For example when someone writes a quick perl script and posts it online, unless they were intending it to be used as a tutorial, far too many of the varaibles are one letter. Also Perl prgrammers tend to put more than one statment on a line by convention. While you can do this in C/C++ it is very rarely seen in the wild, unless somone is trying to be unreadable. So it's not the language, but some of its users.
Philosophy.
As they do with C, C++, Java, Snobol, Forth, APL, C#, etc, etc.
Half of the people programming are below-average programmers. Bad programmers can make life HELL in C, and by the same token good programmers can make life quite easy in Perl.
That said, Perl gets a bad rep, not because good code is hard to read, but because a) bad code is more common in any language which is easy to learn and b) Perl has several features which people mistake for non-readability (that is, non- or inexperienced Perl programmers assume that code is hard to read because they don't know Perl and see these things which scare them):
Just trying to set the record straight.
Oh, don't worry, I'm not blaming you or calling you out or anything like that. Hell that column at the least opened a few eyes, and that's a good thing. It's just that the ST term is one of the triggers that set off some variant of a bitter "programmers need to learn more paradigms/languages" rant in me...
And the voices in my head won't go away until I vent it somehow...
-30-
As far as readability goes I find badly written perl easier to decode than badly written C or C++. Not sure why Perl acquired the reputation of being hard to maintain. I read other peoples perl code all the time and never really had a problem. On the other hand, I have spent days on a small section of C that had includes of includes and with heavy usage of global data. Having the ability to inspect the current scoped symbol table with a print Dumper(\%main::) or Dumper(%package::) is pretty cool.
"Of course you can write some incredibly terse code in Python too, especially with recent language additions."
;-)
Yep. EVERY language can be bent to horrid non-readability.
If you want a language that enforces readability, I would suggest using Perl 6 (the first MAJOR step in the actual implementation of which was just made with the creation of a Haskell-hosted compiler called pugs) and writing a module which enforces your idea of readability. Perl 6 will be the first language to give you enough control that you can write this kind of requirement in the language itself. Common LISP comes in a close second, so use that in the mean-time if you want such levels of dictatorial control. Of course, you could write a module that allowed the rest of your program to be written in CL in P6 quite easily
PS: y=x+++1 Guess what language that is. Answer: C, C++, Python and Java. Perl too if you just add $ before y and x. Programming languages are ugly.
Give it a rest. I was a coworker of Randal at the time that he committed his felonies. My opinion, which was shared by the other coworkers I spoke with ath te time, was that he was guilty of two things: lack of common sense combined with making enemies within the organization.
As an aside, he was probably the best sysadmin I ever worked with. When you wanted something done, he got it done.
Yes I think that's right. Perl gives you far more rope to write unreadable code with. And for some reason people delight in doing so. I really do think that it's part of the Perl culture.
I'm sure I'm not alone in having spent a lot of time thinking about this over the years. I've recently had to both rewrite someone else's Perl code and write some new stuff of my own. What I noticed immediately is how easy it is to write something complicated in Perl and how easy it is to write code that is so terse that no one else will be able to understand it without considerable work. Worse I really think that the dominant Perl culture, as much as there is one, disdains comments and clear code in favor of terse and clever code. And Perl surely lets you do that.
I should add that Perl is my primary language. But I also do a fair amount of Java coding and it sheds some interesting light on Perl. Yes it is incredibly verbose. But it also is much better about forcing you do consider error conditions. Perl by contrast allows you to THINK that you have a working program without informing you of the possible error conditions that exist. Yes I know about -w and use strict and they help. But not everyone uses them. As I said it's still my main language. But there sure are times when I liked to send it to Java school for a little discipline.
On related matters I'd really recommend "Effective Perl Programming" by Joseph N. Hall, with Randall.
I'm still suffering from that, in a sense. It did a big dent in my net assets, as well as make it harder for me to work. There are still countries that won't let me enter, although it's not a US restriction on my travel any more. There are also people that cannot (by company policy) hire a felon, so I'm ruled out there too.
But, I've tried to make the most lemonade from the lemons I've been given.
You give an extremely naive example. Even Perl doesn't allow you to do that ;-)
But, consider this. Perl allows you to postfix your if() statements, like so:
This is much more naturally readable than:Similarly, you can use unless to make code easier to read:This allows you to emphasize that buying food is the norm, and you would normally do it unless you forgot your wallet. The equivalent negative-if form does the exact same thing, but does not allow you to express your intent as well as this does.This is the essence of TMTOWTDI. You don't HAVE to use alternate ways to do things if you don't want to. But it does help most of the time in conveying your intent when you wrote the code, which make it more maintainable.
Once I read someone comparing Perl to the human brain. The brain is a double-edged sword: it can compose the most pleasing melodies and most beautiful literature, but at the same time it can hatch evil plots of large-scale genocide and mass murder. Creativity has a dark side to it. Attempting to suppress that side will severly hinder the creative process. Same thing goes with Perl.
I think Larry got it right.
"...Mark Jason Dominus..."
Oh shit now I know I'm old. I see that name and "Perl" dosn't even come to mine. talk.bizarre does.
Need Mercedes parts ?