Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

What's missing in Perl books?

by brian_d_foy (Abbot)
on Nov 16, 2005 at 02:27 UTC ( [id://508870]=perlmeditation: print w/replies, xml ) Need Help??

I'm doing a bit of research for a couple of book proposals, and I definitely know what I think but I'm not the sort of person who buys technical books (I get them all for free, and in multiple copies sometimes!). The difference between what I think and what people will actually buy can be apples and oranges.

Various editors tell me that tech books don't sell well (where "well" probably means in comparison to Grisham and the like), but that the ones that particularly tank are the ones the start with "Perl &". Allison talks about the spike in Perl book sales this summer due to general purpose Perl books, and with her special editor superpowers, she knows which books do better than others.

So, let's say you've read the Llama, the Alpaca, the Camel, the Panther, the Ram, and so on. Are you still looking for something? What haven't you found that you wanted?

If you're not the sort of person to read books, what do you wish other people would read in books (perhaps so they didn't start all sorts of fires in the workplace)? In the alternate universe of unlimited tuits, free rent and food, and 70 degrees F everyday, what would you put in the Perl book that you would write?

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

Replies are listed 'Best First'.
Re: What's missing in Perl books?
by Zaxo (Archbishop) on Nov 16, 2005 at 03:12 UTC

    I think that something titled "Understanding Perl" could do well. My notion is that it would set out the general rules that perl follows with lots of explanation, examples, and a careful review of exceptions to the rules.

    It should include clear exposition of:

    1. perl contexts
    2. lists
    3. calling conventions
    4. unix, as expressed in perl's design
    5. internals (badly needed now that the panther doesn't cover it)

    That's only partial, more suggestions are invited.

    After Compline,
    Zaxo

      I’d leave internals out and dedicate a whole separate book to them. And a book on them is badly needed, indeed.

      ++ on “Understanding Perl.”

      Makeshifts last the longest.

Re: What's missing in Perl books?
by dragonchild (Archbishop) on Nov 16, 2005 at 04:19 UTC
    Screw understanding Perl. Write something about understanding programming. This mythical book would start with logic, work through metalogic, wend its way through data structures, have some tea and biscuits with people skills, discuss verification of design and function, and, on page 726, introduce the concept of the editor. At no time does this book have a single code listing in any language. Period. Oh, and it'd be accessible to my very smart 10-year old, yet engaging enough for a college student.

    Why, you may ask? Because people can write garbage in every language. And, frankly, 99.9999999% of all programs are GARBAGE, pure and simple. They are unrecoverable, barely maintainable, buggy and insecure dreck.

    "Oh, dragonchild. You're exagerrating." Uh ... no, I'm not. And every single person who reads this that has worked in more than 3 companies is unconciously nodding their collective heads right now. If enough people read this at the same time, there'd be a measurable wobble in the Earth's orbit. It is really and truly that bad.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

      Well, comments in HOP and an Amazon review of it got me interested enough to borrow Structure and Interpretation of Computer Programs from an MIT friend who was a TA for the course. Sorry to say that I don't think it's accessable to a 10-year-old and is definitely a bit light on the people skills part (grin). I'm struggling to find the free tuits to work my way through it, though I've enjoyed what I've read so far. From what I can tell, it pretty much builds up to very advanced programming concepts almost entirely from scratch.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      That sounds surprisingly similar to my comments on Creating an Intermediate Perl Programming Curriculum, except for the language-agnostic aspects.

      I agree that "how to think like a programmer" is the sort of thing I'd love more people to understand. However for (wannabe) Perl programmers there are many language-specific areas that it would be useful to include, ie community resources and the like; it would be difficult to expand that to represent appropriate information about every language out there, but leaving the information out would reduce the utility of such a book greatly.

      For myself, I stopped reading technical books a long time ago. I'd be far more interested in a book of meditations, a collection of things along the lines of Joel's essays from people such as Larry that think meta and create interesting analogies.

      Hugo

        However for (wannabe) Perl programmers there are many language-specific areas that it would be useful to include, ie community resources and the like; it would be difficult to expand that to represent appropriate information about every language out there, but leaving the information out would reduce the utility of such a book greatly.

        I learned how to type in several programming languages before I learned how to program. I would say that I learned how to program about 2-3 years ago. Since then, I've picked up a couple new languages, including my current interest, Ruby. In 2 weeks, I've been able to program at a very high level in Ruby, solely because I know how to program.

        Once someone groks programming, there is no language that cannot be learned and mastered very quickly. The concepts are the tough part - syntax is easy.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: What's missing in Perl books?
by ff (Hermit) on Nov 16, 2005 at 05:31 UTC
    This summer I worked my way through Perl Best Practices and learned lots. To the comment about "more examples", I'd add "and apply the additional style rules and best practices to those examples." I am now working my way through Higher Order Perl and appreciating the graspable ideas and subtle vocabulary lessons on terms that have floated around but never quite sunk in.

    Two books that I'd like to see:
    1. A book full of practical, workable examples of how to use Perl to automate working with MS Office software. Automation of other big PC software packages would be fine too. Throw in some .net also? Show how the code can be modeled on existing VB code, although don't assume any preexisting knowledge of VB. Illustrate use of Spreadsheet::ParseExcel, Spreadsheet::WriteExcel, Win32::OLE::Const 'Microsoft Word', etc. Maybe some Samie? With the zillions of VB books on the shelves, you'd think that at least one Perl cookbook for MS would stand a chance, given the potential direct increases in productivity. (Dave Roth's books are good, but not exactly what I had in mind.)

    2. As a transition to request #2, I still find it valuable to rummage through the Juvenile Emu book (i.e. Learning Perl/Tk, the precursor to Mastering Perl/Tk.) That book is a cookbook of understandable examples (well, if you have patience, and look back and forth, think for a bit about the implications of its examples, and look past its mistakes) that I would never be able to deduce from reading the Tk documentation directly. Yes, the widget.bat examples are vital, but a book with lots of practical examples has been immensely valuable. That's the style of Perl/MS/PC book I'd like to see.

    But this is a transition to request #2: I'd also like to see a full-blown coverage of wxPerl that would teach me as much as the Perl/Tk books did. (Actually, I wouldn't say that I remember all that much about Perl/Tk at any one time; instead the book serves as my long-term memory and I'm able to script-kiddie my way around and make very useful things happen.) I've seen a couple of articles at perl.com about wxPerl and I must admit that I haven't gotten around to actually seeing or making anything work in that environment. But it sounds as though the interface you can develop won't look as old-fashioned as the ones that I seem to be creating with Perl/Tk. Again, I've achieved a lot w/ Perl/Tk and it serves my purpose, but if there was a catalyzing collection of useful examples and theory on another gui, it might prove quite useful.

Re: What's missing in Perl books?
by xdg (Monsignor) on Nov 16, 2005 at 03:48 UTC
    So, let's say you've read the Llama, the Alpaca, the Camel, the Panther, the Ram, and so on. Are you still looking for something? What haven't you found that you wanted?

    I'd like a book which is actually about 'advanced' Perl programming. See my comments at Re: Advanced Perl Programming, 2nd edition -- more of the stuff in the first part of that book (e.g. globs, closures, attributes, Hook::Lexwrap, B, operator overloading, compilation phases), with greater detail and examples.

    Among other things, I'd love a book entirely on XS. And probably a book entirely on POE.

    To add to the laundry list of topics I'd like to see more detail on:

    • concurrent programming (forks, threads, multiprocessor) and IPC
    • software architecture/design for scalable Perl programming
    • unicode (in gory detail)
    • portability
    • security

    I'm not saying there's a mass market for these things, but these come to mind when I think of things that seem to lack a well-written reference.

    (And they do exist somewhere, please let me know so I can go check them out.)

    Update:Some complaints I saw on another thread about how Perl is stereotyped as slow, for scripting only, etc., got me thinking maybe we need "Optimizing Perl" that would cover various problem domains including heavy I/O, database, CGI, numerical simulation, etc.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        Excellent. I'm adding it to my holiday wishlist.

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      I'd like a book which is actually about 'advanced' Perl programming.

      How about Perl Hacks?

Re: What's missing in Perl books?
by tirwhan (Abbot) on Nov 16, 2005 at 07:17 UTC

    I'd buy "Secure Programming with Perl" in a heartbeat. Apart from laying out the base principles of secure programming, it should demonstrate where Perl helps you in avoiding common security traps and where it lays traps of it's own. A comparison with other languages (kinda "If you've been programming (Java|PHP|C), these are the things you should be aware of"), would be useful, and a list (with examples!) of best practices.

    Also, when is "Programming Perl 6" coming out ;-)?


    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
Re: What's missing in Perl books?
by perrin (Chancellor) on Nov 16, 2005 at 04:01 UTC
    The book that I most often wish existed, because co-workers often ask me for it, is a good introduction to object-oriented design. I don't mean the details of how Perl OO works, but rather how to analyze a problem and produce an OO design that solves it. Most of the existing books are either pretty old or full of C++ and Java code, which makes them not very helpful to less experienced coders who mainly know Perl.

      The information is out there, and at some point a programmer who wants to get better has to learn to read some other languages (without being able to write them, neccessarily). I've looked at quite a bit of the OOD stuff you can buy in bookstores. I'm not so sure a book with Perl examples would help much.

      For that I might recommend learning another language, perhaps Smalltalk or Ruby.

      --
      brian d foy <brian@stonehenge.com>
      Subscribe to The Perl Review
      The book that I most often wish existed, because co-workers often ask me for it, is a good introduction to object-oriented design.

      If you don't care what programming language it uses, have a serious look at the Inform Designer's Manual, by Graham Nelson. Skip the first chapters about the language syntax and go straight to the section on the object model. (Yes, you can easily follow the section on the object model without having read the earlier chapters on syntax; trust me on this.) This is without qualification the *best* computer-technical book I have ever seen, and it is an *excellent* introduction to object-oriented programming.

      It's not, of course, the only OOP book you will ever need. After you finish it you will need books that get down to nuts and bolts in the language you're going to be using (assuming that isn't Inform). This is presumably where the books with details of how Perl OO works would come in. Nevertheless, as an introduction to OOP in general, the Designer's Manual is fantastic.

      Incidentally, the text of the book is freely available on the author's website, so if you want to preview it before purchasing a copy of the print edition, you can. The section on the object model starts here, although the real meat is in chapter 2, which really can just about stand on its own.


      "In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

        My wife bought The Inform Designer's Manual. It's the only technical book she's ever bought, and even though she's not a techy she really like interactive fiction.

        I read through most of it and even created some worlds. It certainly affected how I think about object-oriented programming since you specify what objects can and can't do, then the interpreter let's them loose on each other.

        --
        brian d foy <brian@stonehenge.com>
        Subscribe to The Perl Review
Re: What's missing in Perl books?
by spiritway (Vicar) on Nov 16, 2005 at 04:01 UTC

    One thing I'd like to see is clear, unambiguous examples. Time and again I encounter examples of some concept, done in a Perlish way that wholly obscures the intended point by including features besides the one being shown. As a brand new Perler (but a long-time programmer), I find this quite frustrating. I bought just about every O'Reilly book on Perl I could get my hands on, and they all seemed to have this problem to some degree.

    I think part of the problem is Perl's unique ability to do so much with so little. It's tempting to write multi-faceted examples - in fact, it's hard not to do otherwise. This is great when you're writing a program. It's not good when you're illustrating a point.

    So, what I missed were simple examples that displayed one single aspect, and didn't combine several tricks into one short expression. The various tricks are important to know, and often will save time once you know how things work. But from the standpoint of a newbie, they simply confuse, making it that more difficult to grasp the one concept under discussion.

    One other feature I missed in books was a simple listing of the various functions, operators, etc. in Perl with a short summary of how they work. This is easily taken care of in perldocs, but it would be nice to have it in book form. I like to read this stuff, and sometimes I don't have a computer handy.

      I couldn't agree more. I can't think of one Perl book with decent examples. They are always snippets out of context, or the exception. I am not a full-time professional programmer, but I use Perl in my web work. I'm too old to go back to school and get all the theory, so I need step by step how to's.

      CPAN docs are about as bad. I would never have made it without the good monks at the Monastery.


      —Brad
      "The important work of moving the world forward does not wait to be done by perfect men." George Eliot

        The Perl Cookbook is chock-full of examples. Other than that, read the source. You've got all the examples on how to program (and sometimes how not to program) on CPAN, download a module that deals with your problem space and read through it, you're bound to gather some insights that way.


        Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

      If you want the perlfunc in book form, print it out and put it in a binder (or buy Perl in a Nutshell).

      If you're a long time programmer, you shouldn't have trouble reading "multi-faceted" examples in other languages. You already have the concepts of variables, data structures, control structures, and so on. You've probably already run into some of the same tasks, too. This time, it's just in Perl. Either way you go, people complain.

      --
      brian d foy <brian@stonehenge.com>
      Subscribe to The Perl Review

        I've got Perl in a Nutshell. It suffers from the same problem as the others, though perhaps not quite as badly.

        The problem is that many authors work hard to show off the great points of the language, but they sometimes present too many new features at once. For example, I wanted a simple explanation of the 'split' function. One explanation I found showed a clever way of combining split and join to perform some interesting task. Unfortunately, it wasn't clear how to use split or join, nor even what was happening. A better way, I feel, would have been to say: "This is what split does...", and then "This is what join does...", and then combine them together into something interesting and fancy.

        No book or author is going to please everyone. As you said, whatever you do, someone will complain about it. Still, I think it helps to hear what people have to say.

      Yes, more examples!!! "Learning Perl" is the best book I've ever read, (I have about 20 books) multiple examples explaining each thing is great. And all the foot notes keep it interesting (i.e. I don't fall asleep so easily)

      With "Programming the Perl DBI" I'd like to see more examples.

      And I agree that a lot of the O'Reilly books are ambiguous to me.

      I need a lot of pictures and diagrams, I'm really a visual learner. The diagrams in "Learning Perl" that explain Hashes and other data structures are helpful. But I'd like to see a thick book with many diagrams and pictures on data structures. I'm having a really hard time figuring arrays of hashes, hashes of hashes, references of hashes... and ways to access/manipulate the data elements.
      I second the motion: EXAMPLES, EXAMPLES, EXAMPLES.
Re: What's missing in Perl books?
by GrandFather (Saint) on Nov 16, 2005 at 02:50 UTC

    I started by skimming the Camel and tried using it as a reference book. It didn't work as a reference book, at least for me. Later I read the Llama, after the Camel it didn't teach me much and it was just as bad as a reference. (Programming I knew, Perl I didn't.)

    The Perl Pocket Reference on the other hand I use all the time. Appart from minor omissions (like the range / flip-flop operator), it is an excellent pocket reference. So, the book I'd like to see would be "The Perl Reference": an expanded Pocket Reference that doesn't attempt to teach programming Perl, but that provides Programming Perl level of reference material in a Pocket Reference format. That is, take the Pocket Reference entries and expand them to deal with the edge cases and idiom that the Pocket Reference hasn't room for.


    DWIM is Perl's answer to Gödel

        I have a copy, at least at work. We got a copy of the Perl Bookshelf on CD and a real dead tree version of Perl in a Nutshell came with it. I glanced through it, but don't remember much about it. On the other hand, I read through the Perl Cookbook and found that very valuable.


        DWIM is Perl's answer to Gödel
      I've always thought the Camel (2nd edition; I've not owned the 3rd, though I had it out from the library and skimmed much of it) was a pretty good reference book. Can you give examples of things you wanted to look up but were unable to find? (Perhaps we are using "reference book" differently?)

        I think at least part of the problem was that I was very new to Perl and probably didn't have enough nomenclature sorted out. Specific details are hard to remember - this was six months ago after all.

        I recall looking for help with populating HoH and AoH type structures and getting very frustrated that there seemed to be examples that were one letter away (AoA ...) from what I wanted to do, but nothing that addressed what I was looking for. Often there didn't seem to be anything that pointed me in the right direction or I couldn't find it. It took a while for dereferencing syntax to sink in and looking that stuff up seemed to be somewhat of a chore.

        These days I tend more to use the "Perl Pocket Reference" and perldoc, or the Chatterbox.

        I did enjoy reading the Camel and learned a lot from it that way, but not as a reference.


        DWIM is Perl's answer to Gödel

        Grandfather's experience rings a real *BELL* for me, though perhaps for different reasons.

        I came to perl of necessity as a journalist turned flack, who, because of very modest skills with html, was assigned to become a webmaster. Eventually, the html skills got to be fairly decent, but the customers wanted more ( was it not ever thus?). That eventually led to my foray into perl ...which has proven both wonderfully gratifying and intensely frustrating.

        The frustration grows out of collisions with documentation and books that are couched in terms which are undoubtedly both precise and familiar to those who do have a broad CS background... but which I have not.

        So ( at last, he gets to the point), my notion of a ("handy-")reference book is one that can sit beside my keyboard, in my bag, or even on the airline tray in front of me, and provide both answers on functionality and syntax.

        This in NO way deprecates my other notion -- that the Cookbook, Perl - Little Black Book, and even MRE - are references; just not so "handy" unless I'm at my desk and free to take significant time from the immediate task at hand to review or learn the complexities of something not_yet_familiar.

      Have you taken a look at Perl Little Black Book It is a condensed version of the Perl Black Book. I own both, the Little book cuts out a lot of the fluff of the big book. I find it very handy as a code reference and small enough to carry in my laptop bag.

      Thanks,
      Greg W
Re: What's missing in Perl books?
by neniro (Priest) on Nov 16, 2005 at 06:21 UTC
    I'd like to see a book about catalyst, comparable to the "Agile Web Development with Rails", and a 'SICP using Perl' would be quite cool (but would sell bad I suspect).
      Catalyst isn't mature enough to warrant a book like that. Give it 6 months to a year.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

        Though I completely agree, the right time to start writing the book was probably six months ago.

Re: What's missing in Perl books?
by salva (Canon) on Nov 16, 2005 at 08:11 UTC
    CPAN Pearls

    CPAN has become a mess, so many modules, many of them crappy, unmaintained, but still there are hidden pearls, small modules that should be in everybody toolkit but that remain mostly undiscovered.

    And I am not talking about the big frameworks (POE, Catalyst, DBI, etc.) or about modules everybody already knows (Text::CSV, Net::FTP, etc.).

      but still there are hidden pearls, small modules that should be in everybody toolkit but that remain mostly undiscovered.
      Although perhaps not as organized as you might want, this is mostly the goal of my magazine articles. Besides the specific example (and some general handwaving), what else do you want to know about each CPAN module?

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

        Well, your articles are more as stories: you find some problem and then you tell how to solve it. It's great for mag columns but not for books.

        What I would like to see is some kind of reference that goes through the best (hidden) CPAN modules and tells me the pros and contras of every one and why I should use one or another.

        The focus of the book should be just to let the reader know about these pearls and to easily find the best module for his task at hand. Showing how to use the modules should not be required per se, but only to demonstrate the discussion.

      I think that would be a really hard book to write. Chapter 7 of Writing Perl Modules for CPAN (free download here) took a mini-stab at it and it was the hardest chapter to complete. It's very difficult to write an even-handed treatment of someone else's work. It's equally hard to make decisions about which modules to include and how much space to give each one.

      This may be better done as a series of articles, perhaps modeled after the awesome Perl Advent.

      -sam

      Not a book, and only once a year, but www.perladvent.org has had the odd cracker (groan) in it.

      The second edition of Advanced Perl Programming is mostly a "CPAN Review" of sorts (but it's mainly about what you would call the "commonly known" modules). The problem with a book about CPAN is that it's always changing. The topic would be more suited to a periodical publication or website.
Re: What's missing in Perl books?
by Your Mother (Archbishop) on Nov 16, 2005 at 04:07 UTC

    "Teaching Perl" or even "Teaching Computer Science with Perl." It's the book I'd write if A) I had an extra 1,000 hours in the year and B) my Perl were at a higher level than I could get without another extra 1,000 hours.

    It would not sell well, but it would fill a wonderful niche, be good for advocacy, and could probably support a premium price. If it had a companion of "The Perl Workbook" or something for classes then those might take up the sales slack.

    I would probably publicly attack such a tome unless

    $its_Perl > $competent and $its_instructional_value >= $its_Perl

Re: What's missing in Perl books?
by blazar (Canon) on Nov 16, 2005 at 11:25 UTC

    My very first exposure to Perl has been through an old copy (Perl4, I think - in Perl5 days) of the Llama book. For the rest I've not read any book but for sample chapters found online, and most of my education was carried out with the help of clpmisc (which eventually I had to leave as it became too huge a time sink) and the docs, with a mutual exchange, for I was often referred to the latter, and when I found something I couldn't understand in them, I asked for clarification; and it is now continuing here - because there's always something new to learn and I'm not only talking about very advanced stuff, but also about basic stuff that that has been inadvertently sidestepped for a surprisingly long time.

    Taking all of this into account, two books that I'd like to read are:

    The former, both because it is harder for me to grasp OO programming concepts in general, and OO Perl programming in particular, than other generic concepts and techniques, and because the sample chapters and other stuff I read from Damian positively influenced my judgement. Or biased it...

    As far as the latter goes: ditto as above wrt judgement bias! But most importantly, even though I've not received a formal CS training, it seems I have a natural penchant for FP techniques and concepts, probably as a consequence of my mathematical interests. (I'm studying Physics, but I should have chosen Mathematics instead!)

Re: What's missing in Perl books?
by jacques (Priest) on Nov 16, 2005 at 05:40 UTC
Re: What's missing in Perl books?
by perlsen (Chaplain) on Nov 16, 2005 at 12:47 UTC
    Hai brian,
    This seems nice suggestion, everyone searches the answer for to solve their own work to complete in faster manner. In my experience i saw some my friends refered the books in following ways,

    Looking for proper explanation like syntax and its use in real time. Where they fit for their wok to complete. Basically they are looking differnce questions. somewhat likes My, Local , our differnce questions.

    This explanations would give some good idea to Where the "My" fit and where "our" is fit. Example of problems occurs in practical real time and the solution for that problem answers.

    categorise the Problems like file related, Regexp, and directory related...

    And i would like to suggest To prepare the common FAQ like book or site. that is the collection of Most user asking questions in Perl monks site.

    Everyday the new user asking question somewhat older ones and searching for their answers. if this Book or Site created, Most of the user Would get clear idea and They wont ask these kind of questions.

    And one thing if anyone wants to refer the new book the cost of the book is high. so they finaly leaves their buying idea and they start trying for alternatives. So all the books should available in less cost or free of reference.

    Thanks,
    perlsen
Re: What's missing in Perl books?
by Anonymous Monk on Nov 16, 2005 at 16:18 UTC
    Perl 6. It is a huge beast. We need more Perl 6 books.

        Perl6 isn't done yet. Hard to document a very quickly moving target.

        Hard, yes, certainly. But not quite impossible.

        The fun thing about Perl 6 in its current form is that almost all changes are in syntax and things that Perl 5 didn't support. And even when a major Perl 6 feature is changed somewhat, the underlying principles are practically set in stone and stay the same. It's "just" the details that people work out now.

        Certainly a migration book can already be written, as it is already know how Perl 5 things will behave in Perl 6. Well, except for very minor things like the flipflop. But for that, you can leave in a stub. It's not a show stopper.

        When Perl 6 is in beta, re-read the book(s) and update everything to current. Run the test suite for the example code, and repeat that until everything passes again.

        Perl 6 is a moving target, but that doesn't stop the Pugs team from maintaining more than 8000 unit tests, lots of documentation and of course the Pugs code base. And it shouldn't stop anyone from writing a book.

        If you're not up to it, don't worry. Other people are, and the books will be there by the time Perl 6.0.0 is set free. Some even long before.

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Re: What's missing in Perl books?
by Anonymous Monk on Nov 17, 2005 at 07:25 UTC
    All of the Perl books I've seen are small, very drab, and extremely flat.

    What we need is a coffee-table Perl book. Huge pages, most of them vibrant, colorful photographs. And it should be a pop-up book. That's something I'd pay good money for.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://508870]
Approved by dug
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2024-03-19 08:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found