Rassie's Doghouse

DISCLAIMER This post is highly subjective, biased and mostly unfunded. Thank you for understanding.

A new book on Perl has been published. No, it’s not “Modern Perl” by chromatic (at least not yet) and also not the “Effective Perl Programming 2nd edition”. What I’m talking about is “Der Perl-Programmierer” (that’s German for “The Perl Programmer”) by Jürgen Plate. Now, I must admit I know nothing about Jürgen, and he is probably a good professor, teacher and maybe even a good Perl hacker and I don’t want to say anything bad about him. I didn’t even read his book — I’ve only seen the table of contents. Despite that, I wouldn’t recommend it, I’ll probably even recommend strongly against it and I would even recommend that everyone in the Perl community makes sure this book doesn’t get a wide reading.

My main problem with this book is that it’s totally unhelpful for Perl at large. It’s a 2010 work, but it seems very unmodern, at least not “modern” as in “modern Perl”. “Perl Best Practices” have done a tremendous job separating Perl’s functionality into “use it” and “use it only when you know what you are doing” and my personal plan for teaching Perl would be teaching newbies the “good” stuff only — and this book seems to fail miserably at this.

Here is what I don’t like in detail:

• In the chapter about control structures, the goto statement is getting a separate subchapter. Call me purist, but I don’t believe that the only useful form of goto, the one with a subroutine reference, would be described, especially since subroutine references are explained some 70 pages later. The other goto variants should definitely be off the radar for newbies.

• The eval function is getting one single page of attention or maybe even less. I wonder whether the $@ localizing problem is explained somewhere in the book?

• Whole five pages are dedicated to the “Perl 6 outlook”. How much useful information about Perl 6 can you actually put in that space without alienating people? I would have understood something like “There is Perl 6 around, read all about it in our other book” in the introduction, but a separate chapter of five pages?

• Chapter 2 is “Debugging”, including “Perl Debugger”. Way before the chapters on packages, modules and even complex data structures. Needless to say, that whole chapter is ten pages long, probably including the infamous “This page has been intentionally left blank”.

• I’m not entirely convinced that a chapter on documentation should go before the one on packages, yet it does.

• The chapter on regular expressions is available for free reading. It’s horrible, from what I can see.

  First, we are told that Kleene created them and “adapted for the information technology”. Fine, you could think, never mind the theory, not everyone needs to know about Chomsky hierarchy. However, a paragraph later you read “Regular expressions in Perl are based on an NFA (non-deterministic finite automata), which does the following….” Besides that, the author tells us that Perl only has matching (// or m//) and replacing (s//) regexps only to introduce tr// later on.

  Great examples for replacement are $string =~ s/ä/ä/g; for HTML, which is still common in Germany, but utter bullshit even there. Looking for something in a file? “For this special case (and for searching in arrays) there is a function called grep which we’ll discuss later, since we are solving the problem with simple pattern matching”. Yes, it’s solved with a while loop — and we can consider the readers lucky, since the author only wants the matching lines printed. Otherwise we’d probably get the infamous for-push or a while-push pattern. Oh and by the way, tr// gets almost three pages of treatment, almost as much as m// and s// together.

  Pure evil follows. Words can’t describe my feelings about the ignorance of Unicode in 2010. Probably the same words that go for Whitesmiths indentation of the code in that whole chapter.

Whether `/.+/` accepts umlauts or not depends on your setup. Therefore don’t forget to put the following lines at the beggining of your program:

1 2 3 4

use POSIX; use locale; # In case it's not yet set: setlocale(LC_CTYPE, "de_DE.ISO-8859-1");

• Following the “Regexps” chapter are the ones called “Program configuration” (either with Perl code or with key-value pairs, no idea what they tell you there), “System information” (stuff like getpwuid) and “Processes and signals” (fork and waitpid). I consider it by any means advanced material, which shouldn’t come this early in the book. The author probably has a strong system administration background, so I guess that would explain it.

• Whole ten pages on “Internationalization”, which seems to only cover locales. I’m happy I don’t have the book here, since I’d probably go killing people. Again, i18n is a must-know topic in 2010, but covering it on ten pages won’t do it. Even the Unicode article by Joel Spolsky is probably a bit longer than that. No mention of Locale::Maketext (thank God!) but also none of any other translation frameworks. Not important I guess…

• The “Modules” chapter begins with a “Using modules” subchapter, which makes me wonder — how did the author manage to recommend many CPAN modules without explaining how to use them? And he did recommend a lot in the earlier chapters, starting with List::Util, Regexp::Helper and Data::Dumper.

• Whole 34 pages on object oriented Perl in a 1200+ pages book. Classic object oriented Perl. No Moose, no Class::Std or any other bless-free framework, as far as I can see. This chapter will be the one I’d be wanting to look into — I can’t believe you can write a book on Perl in 2010 and not mention Moose.

• All of the following chapters are dealing with “Practical Perl”, which is more or less 800 pages of “look what I think is cool”. If he had taught people to use CPAN properly, there would be no need for that. Topic selection is more or less random — while I find “Text manipulation” something that’s probably worth it, taking almost 100 pages for “GUIs with Tk” is a waste of time and paper. Same goes for calling a chapter “MySQL Databases”, introducing MySQL in general for about 60 pages, probably mixing up MySQL and generic SQL while at it, and then trying to fire up DBI with MySQL over 30 pages. “Socket programming”, “E-Mail with Perl” (including writing a small MTA), “CGI and HTML” (yes, CGI as as Perl module too, no Catalyst, Dancer, CGI::Application or anything else of the sort, but instead including a sub-chapter on CAPTCHAs), “Math with Perl” and even “Hardware Programming with Perl” (first sub-chapter of which is called “you must be root”) are all interesting topics, but are they really needed in a Perl book intended for newbies?

As I went through the TOC, my WTF per second ratio went almost through the roof. This book could have been really good in 2003 or even 2005. In 2010 however, it is harmful for Perl the language, for Perl the community and ultimately for the newbies themselves, who will be easily alienated by this book — it’s not like there were no alternatives for Perl around. It’s not 1998, right?

Maybe we should forget about writing a Perl 6 book for a while and start by writing a Perl 5 one? I for myself still hope for some good mixture of PBP, HOP and chromatic’s new one. The one I can then whole-heartedly recommend — both Camel and Llama books seem a bit dusty right now.

I must admit, I’m a bit underwhelmed by Enlightened Perl’s Iron Man competition. They’ve essentially replaced Planet Perl because every blogger from the Planet now also gets syndicated to the Iron Man (could you please work together guys and kill one of the planets?) However, the blog posts’ medium quality hasn’t changed at all — and neither have the subjects. It’s still the same: some “aren’t you using Perl 6 already? 10 reasons why you should!”, some “all hail Moose!”, some “new Padre released, it’s just as powerful as Emacs, but only for Perl stuff”, and also some “Did you know CPAN rocked?” That last bit of sensationalism is getting on my nerves.

Yes, I know, CPAN is great. I even agree. CPAN is great because of the sheer amount of data collected. But it’s a complete disaster otherwise. I might be a bloody newbie in Perl world, but everytime I’m confronted with CPAN, I’m lost and confused — and there is a major flaw in CPAN causing that feeling: every module in CPAN is essentially an open-source project, but nothing at CPAN works under this assumption. It’s full of closed down silos.

Let’s start with a simple example: toying with CPANPLUS::Dist::RPM (or maybe it’s this link, who knows which is the canonical one) at work I’ve noticed it hangs sometimes, consuming 100% of CPU essentially doing nothing worthy. Let’s now assume I’d like to investigate this problem, but I don’t know if this is a bug or a mistake on my side.

So I go to the CPAN page of the package. Oh, there is a discussion forum, let’s click on that! Too bad, it’s broken. Bug reports? Oh yeah, there are whole three of them — none of which is my problem as far I can see. And I can actually barely see, since the visual component of that bug tracker makes Bugzilla of 1998 look good. But I still not sure that’s a bug, so I wouldn’t file one. What’s next? Maybe there is something new and relevant in development code in the revision control system? Oh wait, there isn’t any. CVS, SVN, Git, Mercurial, anything? Nope, no such thing on CPAN. Only release tarballs and some weird release differ tool. No revision control for an open source hosting in 2009, am I looking right?! Only way to ask something is to ask the author per e-mail? What about collaboration, patches, interactive community process for single modules?

Dear Github guys, if you happen to read this, please host the CPAN for us! Revision control, bug tracking, code review, documentation parser — if you could add some discussion forums, you’d be a perfect CPAN hoster!

So CPAN is so far: EPIC FAIL in discussion forums, somewhat FAIL in bug reports, EPIC FAIL in encouraging open development. Those are basic open source functionality nowadays, you know. And those are not nearly scratching the surface of critisicm.

Every other page on CPAN is different in design and interaction, there is no common and consice web interface, many different docs/search/rating mirrors which ultimatively produce a lot of Google spam. An awesome lot of cruft, a lot of broken modules which pop up prominently as first search result, no clear indication if a module is abandoned or actively developed. Even the most potentially useful features like dependencies’ resolution are crippled — dependencies work only in one direction, whenever I’d like to know how people actually use some module, I’m lost again. This is CPAN of today, confusing and rusty. CPAN is naked and it seems nobody wants to point that out. I do not want to think that nobody actually notices.

The situation with CPAN is symptomatic for the whole Perl community. Whether it’s Perl.com, Perl.org, Perl Mongers site, Perl Monks, use Perl or CPAN, it’s always the same: unreadable and misaligned content, incomprehensive navigation and straining colors, self-representation on the web coming straight from 1999 ¹. All the good code in the world and the power of the language won’t help anyone as long as people are alienated by ugly tools, visually and technically. Why can’t CPAN have the visual docs design from http://perldoc.perl.org, which at least features a syntax highlighter? Some CPAN mirror I land on every now and then from Google is even uglier than the one at http://search.cpan.org. Do we care at all about how those sites look? Do we care about fellow Perlers, about how hard they have to look for information? Why isn’t there some central site for Perl information? Why is every Perl project so independant that things like Perl Iron Man happen without cooperation with Planet Perl? ²

Perl community has so many possibilities but most of them stay unused. Most people are probably content with what they have and wouldn’t want to change anything. It’s fine, Perl’s way certainly supports that, but then we can forget about Perl revival. It’d be a shame, but we’d have only us to blame, not some superstitions about Perl being a “write-only language” or “ASCII soup”. The first impression counts and many newbies might not make it to the code at all — they’ll struggle with finding tutorials first. They won’t find out why Perl is great and will leave for other, probably inferior, languages, because they’ll be reading some ugly outdated quickstart documentation from 1997. They won’t find the shiny things, but they should be able to — as their first Google search result.