Long time readers will remember when this journal was nothing but a long diatribe on Perl books. I've broadened my horizons recently, but I'd like to return to books briefly. You should be warned that there may be bitterness in this journal entry as it was partly brought about by hearing the (very disappointing) second half of 2001 sales figures for Data Munging with Perl.
Last night I was talking to ziggy and pdcawley about forthcoming Perl books. There are a number of books in the pipeline that sound really interesting. But we started to wonder just how well the kinds of books that we'd buy would actually sell.
There are a limited number of Perl programmers out there. From my experience, the majority of Perl programmers don't really care about the "software engineering" aspects of Perl - and I'm talking not about "bleading edge" stuff like aspects or attributes or currying or design patterns, I'm talking about sensible variable naming or resuable code. Now I realise that people reading this will probably disagree with me. Of course you care about all of those things. But my point is that you are not typical Perl programmers. By knowing about this site and these journals, you're part of the Perl community. We know about the importance of good code design and we either know how to achieve that in Perl or we'd be interesting in learning by buying the appropriate books.
But I don't think we're a very large group. There's probably only a few thousand of us. And no sane publisher is going to publish a book that will only sell a few thousand copies.
So these points were raised last night and someone raised a counter-argument. Even if only a relatively small number of people buy an advanced Perl book, the majority of Perl programmers will still benefit as the people who read the book will produce improved tools and modules that we can all benefit from. Last night I thought I agreed, but thinking about it I'm not so sure. I don't believe that the majority of Perl programmers will ever hear about the improved tools or the newer modules. Most of them don't see Perl as something that they need to "keep up to date with" and even if they did, they wouldn't know where to go.
Last year, I ran a lot of training courses for a large company. This company had a lot of Perl programmers. But the majority of these programmers knew nothing about CPAN or use.perl or their local Perl Mongers group. Wherever they'd learned Perl from, they hadn't been told how to join in with the Perl community. And that means that there are books and trainers out there who are teaching Perl without pointing people at important Perl resources.
So what do we need do? We need to draw people into the Perl community. We need to find people who consider themselves Perl programmers and show them what they're missing out on. We also need to grab people on their way into Perl and make sure that they know how to get the most out of Perl.
To bring it back to books, ehilst I do think it's great that we have new advanced Perl books to look forward to, I also think that we need to have better books that beginners will read. For my next book, I was considering something that went futher on the data munging path, but now I@m thinking it might be more useful to write a beginners CGI book based on nms - sort of a "CGI/Perl Cookbook" but done right :)
And no sane publisher is going to publish a book that will only sell a few thousand copies.
Well, the 2nd edition of the French translation of the camel book only sold 6600 copies. But O'Reilly France still wanted us to translate it.
And we insisted to add a special paragraph written by grinder (leader of Paris.pm) in the introduction, which tells the readers about "Les Mongueurs de Perl", so that they know where to ask for help in French. I guess this is part of making people aware of the existence of the Perl community, and trying to bring them in.
It is out since december 5, but we have yet to learn about someone that subscribed to our list thanks to the book, though.
Re: Back to Books
barbie on 2002-02-04T00:18:26
It would be very nice if every Perl book had a short introduction to what the Perl community is about. This would include a link to the Perl Mongers site, along with the Conferences, including YAPC, and the few well regarded sites such as use Perl, where further information can be sort.Most books could withstand a standard half page advert for the community, and seeing as O'Reilly have made great efforts on behalf of Perl, I'm sure it's something they would consider.
Where have these people learned their Perl from? From hacking other people's scripts, downloading examples and fiddling with them probably.
People are too busy to read books. This has to be done now and we haven't got time for you to read the camel first. Download an example, hack at it, and get it in place.
Maybe what we need is more cookbook type books after all, rather than more tutorial type books. Books for people that don't want to have to read the entire thing but just grab the book when they need help doing a task. Basically when they just need to know how to do something and just that something.
I see no reason why this should just be limited CGI however. I'd love a perl XML cookbook. I know I'm looking forward to the mod perl developer's cookbook. Maybe we even need a "writing scripts cookbook" that has things from command line options to testing code.
It's all in the marketing. Maybe we should have something called "Instant Perl Code" which just has examples of 'stealing' code by using modules from CPAN to do every single example in the book.
Re:Cookbooks
chaoticset on 2002-01-22T16:22:51
I want to buy every book I see on Perl, usually...I have an old, voracious reading appetite, so my brain still goes "You need more books! Get the book!"That having been said, it would be extremely informative (plus, it would play to the "We need it now!" audience) to see a book that presents a case study of using old code for a new solution. "We needed to solve Q problem. First thing, we went to CPAN. Here's where CPAN is..." and then explained how to use/modify/twist previously-written code. (Even a general, code-inspecific manual would be really helpful.)
I wonder what the O'Reilly title for that book would be. _Leveraging Perl_?
Is there some book that's the granddaddy of this topic that I just don't know about? Or is this a niche yet to be filled?
Re:Cookbooks
jhi on 2002-01-22T17:43:48
> I wonder what the O'Reilly title for that book would be. _Leveraging Perl_?
_Stealing Perl_, obviously:-) Re:Cookbooks
babbage on 2002-01-22T20:40:27
No no, _Steal This Perl_!
:)
someone should ask people what kind of books they would like to see...people not part of our incestuous little corner of the computing world. It seems like too many books are written by the author for the author instead of by the author for the reader. I've found few reasons to part with $40+ lately
Re:It seems like...
davorg on 2002-01-22T16:48:54
our incestuous little corner of the computing worldThat phrase pretty much sums up how I'm feeling right now. We can produce all the clever Perl books that we want and outside our little cosy world it means nothing. No-one cares.
I've spent so much of my time involved with the Perl community over the last 3 or 4 years that I started to believe that it was somehow important. And the truth is that it isn't at important at all to most of the world. Not even to most of the IT industry.
I've had a couple of telephone interviews over the last few days. Obviously my CV mentions Data Munging with Perl. People who are interviewing me are Perl prgrammers. They ask me what my book is about. They've never heard of it. And it's not just my book (I wouldn't be surprised if it's just my book) all they have heard of are a few Perl for Morons books and perhaps the Camel and the Llama (althought, usually it's the first edition).
Perl 6 looks like it's shaping up to be really good, but I wonder if we're completely wasting our time. Who will hear about it? How will they hear about it? Why would they switch from badly written Perl 5 to badly written Perl 6 when they can switch to Java or C# (or so the marketing departments will say)?
I guess what I'm saying is that advocacy and evangelism should be our first priorities. Who's dealing with those? How can I help? Where do I sign up?
Re:It seems like...
hfb on 2002-01-22T18:23:13
Well someone must care as at least a few books sell but, no, in reality most of the world doesn't give a damn not now, not ever. Computing, like plumbing, should be a fixture in every modern home thatonly gets noticed when something fails. It is less about people and more about where computing is heading. We engineers are always in the green room...not really in the audience and not front stage either...like a fuzzy netherworld.
Will anyone care about Perl6? I don't know the answer to that but who knows people may surprise us. The day we cease to have the capacity to be surprised is the day ennui will be the death of us all.
And the thought of advocacy makes my stomach turn anymore...those who might be good at it know the slow plodding futility of it and those who become cheerleaders overnight do us no favours. The Dynamic D's would seem to be our best hope at advocacy since they are both congenial to a fault and are comfortable in the limelight. The rest of us should just keep shop and make main street look nice.
That means there's a section on using perldoc and the CPAN and finding the real Perl and Apache and MySQL mailing lists and asking good questions in a Slash book.
Perhaps a solution is to find where "nascent" programmers congregate (read, "leech questionable code") and promote the good stuff, time after time after time.
Re:I have said this before...
FoolontheHill on 2002-01-23T12:05:23
Very True.
I read somewhere recently but I cannot remember where that you can judge a man not by the way he treats his peers but rather by the way he treats those who he is superior to.
Most people need to get along with his/her peers and obvious there superiors but there is only really a moral compulsion to behave appropriately to those who you are superior too.
In this case it obviously even easier to behave poorly to people who don't understand the culture or the language of Perl because there is little or no two-way relationship. A good mentor-pupil relationship should be two way. Allowing the mentor to learn whilst teaching the pupil. I think that Perl People tend to be pretty damn friendly on the whole.
BTW I think the paraphrased quote thingy came from Harry Potter - Goblet of Fire - not exactly the I-Ching.
Re:I have said this before...
pudge on 2002-01-23T15:09:41
I read somewhere recently but I cannot remember where that you can judge a man not by the way he treats his peers but rather by the way he treats those who he is superior to.
The problem is that it is rare that anyone is superior to anyone else. I am superior to my children, certainly, but I am not superior to the moron who comes into clp.misc asking how to get the length of a string. I know more than he does about Perl, but I am not superior to him. And as such, I don't treat him as though I am superior to him. I treat him as a peer who should know better. And maybe that's the problem.:D comp.lang.perl.misc and "attitude"
pne on 2002-01-28T08:20:26
It's not as if this issue hasn't come up on clpm before. If I recall correctly, a common response talks about burnout. Some people feel responsible for responding to each newbie's question before they get a questionable, or wrong, or brittle answer from another newbie and leave thinking they just received the One True Answer (after all -- hey, it works!).
This is coupled with a large number of newbies who ask similar questions time after time, many of which are answered in some way or another in the FAQ, and the newbies who have problems "partitioning their problem space"(?) -- for example, asking an HTML, JavaScript, or CGI question on clpm. A good answer, some feel, would be to direct them to a resource which knows about HTML, JavaScript, or the CGI, since the answer to their problem is often independent of the programming language they are using; however, many people don't take kindly to such redirection.
Another thing some people worry about is that people will look up a question in Google Groups or another Usenet archive and see a wrong answer which was not subsequently refuted by someone with a better answer, or which points to consider before implementing the other answer, and they think they've found the answer, so some people on clpm feel pressured to respond to questions which have been answered sub-optimally, in their opinion.
How do you propose to solve the problem? (Serious question.) There are only so many good Perl programmers, and so many newbie questions. And, as I said, a fair number of newbies have one or more of the following faults which some people find stressful after a couple of months: (a) don't read FAQs or other documentation; (b) can't partition their problem space and ask what some consider non-Perl questions; (c) do not react kindly to suggestions to re-ask their question in a more suitable forum. There are probably a couple I've forgotten. Where are you going to find people who are (a) competent enough to answer Perl questions and (b) patient enough to deal with newbies in the way you appear to be suggesting? Where are these ambassadors of goodwill, as it were, supposed to come from?
I've met and worked with competent perl programmers over the years who have heard of comp.os.lang.perl.misc, if only because it was mentioned in the camel and llama. But they don't actually participate because they've seen what happens to newbies who ask questions.
These are people that we want in the community and we have successfully alienated them.
So, what to do? Let's be ambassadors for our community. Listen to people. Learn. Teach.
Feel free to go ahead and set the good example on comp.lang.perl.misc by learning, teaching, and listening to people. Perhaps your presence will lighten up the tone a little -- and I do not mean that sarcastically. I do mean that there's only so much you can ask people to do if you don't contribute yourself; wishing that clpm were a friendlier place won't make it so.
