My reading of each of the commandment, I found out, follows a rigourous processus. I always punctuate the disclosure of the commandment at hand with an outraged "preposterous!". At around mid-section, it unavoidly morphs into a "hmmm, I can see his point.. but it ain't for me. It just doesn't jive with my vibes". By the time I've made it to the end, though, it is rare indeed that I haven't seen the light, donned the ritual sackcloth and ashes, sworn to atone for my sins and to walk the straight and narrow from now on.

Seriously, I consider PBP to be the best programming investment I did this year. It is worth its weight in depleted uranium bars, and is twice as entertaining. I recommend it heartily to all my friends, whether they be Perl programmers or not. It's that good.

-- `/anick Champoux on PBP

Perl and C++ are very different programming languages. Nonetheless, I use both regularly and recently had the pleasure of reading two similar books about each:

Personally, I was delighted to see these two books appear. For Perl and C++ are both mature, TMTOWTDI languages and now is an opportune time to reflect on the hard won experience of the past 10 years and lay down the law on how best to utilize these complex languages. Doing so clearly and with authority -- as both these books do -- is especially beneficial to programming teams suffering chronic maintenance and teamwork problems at the coal face.

This meditation compares and contrasts these two fine books.

PBP contains 256 guidelines and weighs in at a whopping 542 pages. CCS weighs less: 101 guidelines, 240 pages.

Why is PBP bigger? It covers more ground, with excellent chapters on documentation, testing and debugging -- missing from CCS. Further, PBP is more self contained than CCS, convincingly explaining the rationale behind each guideline in detail, and with fewer external references. Finally, PBP on occasion invents new art, such as unveiling a suite of funky new CPAN modules authored by TheDamian (as if you couldn't guess;-). CCS, on the other hand, deliberately eschews invention. And strives to keep guideline rationales short, often by providing references to external material.

Though longer, PBP is missing a few nice tips from CCS, such as guidelines on concurrency/threading, error-safe code, automated builds and code reviews.

Generally, PBP emphasizes "Robustness, Efficiency, Maintainability", while CCS seems more concerned with "Correctness, Simplicity, Clarity, Safety" along with "uniformity in the right dimension" and "creativity in directions that matter".

Another conspicuous difference is Conway's gutsy attempt to persuade readers on code layout issues, such as space versus tab indentation and braces placement. Personally, I applaud Conway for this (though doubtless others booed). In any case, I found Damian's carefully reasoned arguments convincing. In contrast, CCS's first guideline, Don't sweat the small stuff, timidly exhorts its readers not to attempt to enforce personal taste on code layout.

As for similarities, both books, in addition to language specific recommendations, offer general guidelines applicable to either language; both books, for example, extol the virtues of version control. In addition to specific similar guidelines (detailed below) both books emphasize similar general principles, such as scalability, abstraction, encapsulation, and preferring to find errors at compile time rather than run time.

Conway and Alexandrescu: Separated at Birth

At first glance, Conway and Alexandrescu seem spookily identical:

On second glance, admittedly, there are some glaring differences:

Some Similar Guidelines Found in Both Books

Extra Tips That Might Be Added To PBP From CCS

Extra Tips That Might Be Added To CCS From PBP

What Might Be Added To Both Books

Books

Other References

Updated 19-oct: A few extra tips plus minor improvements to wording. 23-oct: added more references. 20-jan: added opening `/anick quote.

Comment on Two Different Languages: Two Similar Books (PBP and CCS)
Re: Two Different Languages: Two Similar Books
by pg (Canon) on Oct 16, 2005 at 15:55 UTC
    "For Perl and C++ are both mature"

    Yes, they are both mature, but Perl is also evolving, especially with the active development of Perl 6 (actually even Perl 5). Being mature and evolving are not mutually exclusive, in this sense, Perl shares a path that is more similar to Java's.

    This evolving gives perl a even brighter future.

      Yes, they are both mature, but Perl is also evolving, especially with the active development of Perl 6 (actually even Perl 5). Being mature and evolving are not mutually exclusive, in this sense, Perl shares a path that is more similar to Java's.

      To be fair C++ isn't standing still either. See Strousop's The design of C++0x (pdf) for example.

      It's just a bit harder to spot since perl doesn't have the advantages of multiple implementations and a standards body ;-)

      Technical Report 1, a specification for new functionality being added to C++'s standard library due sometime around year 2008. http://aristeia.com/EC3E/TR1_info_frames.html

      You speak too soon. Perl6, vs C++/TR1. Now with Hashes!


      Evan Carroll
      www.EvanCarroll.com
Re: Two Different Languages: Two Similar Books
by ioannis (Curate) on Oct 16, 2005 at 23:58 UTC
    From my prospective, it is more important to remember that books on style and practices are meant as general guidelines, they are not laws of nature that always remain true. Writing programs is too complex an endeavor to conveniently fit into methods of right an wrong (tm) : after all; how do you know which of the (possibly conflicting) qualities are important to me, how do you know my (partially contradictory) goals, and how do you know my present constrains? You have no way of knowing. It would be nice to simply follow rules. Does this work, in each an every case? For rules must work in every case; otherwise, I cannot stay confident whether this rule will lead to harm or profit.
      First off, I, and many others within the Monestary will agree that there are times when (nearly) all the "best practices" will be broken for good reasons. It has even been stated that some of the "best practices" possibly aren't good for some people/groups at all.

      So, yes, they are best to be looked upon as guidelines, not laws. (And, the title of the book specifically says these are not to be looked upon as laws)

      Having said that, those who have extensive experience coding in their language of choice are attempting to communicate a set of "best practices" such that those who are not as far along the path as they are, might be able to avoid some of the pain they've experienced along that path. Ignoring them is probably not in your best interest.

      So, if you are uninitiated, and your point of view is often one expressed by those who've not been on the path very long, you will be better off in the long run if you choose to listen and incorporate as many of the "best practices" as you are able. It will also probably be helpful if you continue to attempt to incorporate these practices as you evolve. As you do this, there will be some practices that you just don't agree with; don't lose any sleep over them, as you said, they are only guidelines.

      -Scott

        One of the things that you learn as an art major is that all rules are meant to be broken when 'needs must'. The hard part is to know just when that is.

        --hsm

        "Never try to teach a pig to sing...it wastes your time and it annoys the pig."