Re: A wide open niche in Perl publishing...

From: J Krugman (jkrugman345_at_yahbitoo.com)
Date: 02/16/05 

Date: Wed, 16 Feb 2005 04:48:01 +0000 (UTC)

In <4PGdnaAejrxc84_fRVn-rw@adelphia.com> Sherm Pendley <spamtrap@dot-app.org> writes:

>J Krugman wrote:

>> Unless I've been looking in all the wrong places, it seems to me
>> that there's a wide open niche in Perl-related publishing (and in
>> all of programming-related publishing, for that matter). I don't
>> even know what to call the type of book I'm thinking of. It's
>> something in the spirit of the (awesome) Perl Cookbook, but dedicated
>> to larger-scale design issues, instead of bite-sized solutions.

>I think you've been looking in the wrong places. The kind of large-scale
>application design issues you're talking about aren't language-specific,
>and books that talk about them tend to use pseudo-code and/or diagrams to
>illustrate their points.

>The assumption is that someone who's designing applications at that scale
>will be familiar enough with the target language that they'll have no
>problem translating the abstract ideas from the book, into concrete code in
>the language of their choice.

>Have a look at "Design Patterns", for example.

Well, I just couldn't disagree more. I *am* very familiar with
"Design Patterns" and several other books of the same ilk, familiar
to the point of nausea, actually. Those books are good as far as
they go, but they are no substitute for a functionally coherent,
detailed, extended example written in a real programming language,
not in pseudo-code.

Three reasons.

First, a working extended example cannot be content with presenting
beautiful theoretical schemes, featuring infinitely sensible
abstractions out the wazoo and layer upon layer of clever indirections,
if come run time the code ends up being slower than molasses in
January, or if, in the concrete problem at hand, the implementation
of gorgeous design pattern A happens to conflict in subtle ways
with the implementation of exquisite pattern B. A real example
has to be, above all, functional, which may or may not agree with
higher-level considerations. (Have you seen the guts of perl???
How's *that* for pretty? Most of perl internals would give the
GoF seizures.)

Second, programming books written in pseudo-code implicitly assume
that all the important design decisions in programming are essentially
orthogonal to the choice of language, which is far from the case.
The particular facilities and limitations of a language (is it
strongly typed? what support does it have for namespaces and scopes?
what support for exceptions? what support for callbacks? etc.) are
often decisive to the ultimate shape of the code. In fact, the
choice of language for a project is in itself a major design
decision, and this choice is based, at least in part, on how the
strengths and weaknesses of a language impinge on the project's
goals.

Third, if theoretical books like "Design Patterns" where enough,
books like "The Perl Cookbook" wouldn't sell nearly as well as they
do. Most of the basic Perl information and design advice in "The
Perl Cookbook" is already present in "Programming Perl", but for
someone learning the craft of programming it is invaluable to see
how exactly (and how far) design principles are put into practice.
"The Perl Cookbook" does a great job at showing the reader how to
code Perl "in the small". I think there is very much of a need
for a follow up (or twelve) that show in gory detail how one programs
Perl "in the large."

(I sure hope that someone at O'Reilly, or Manning, or New Riders,
or Apress, etc. is reading this.)

jill

jill 

-- 
To  s&e^n]d  me  m~a}i]l  r%e*m?o\v[e  bit from my a|d)d:r{e:s]s.

Relevant Pages

  • Re: Want to create a website using perl and CGI
    ... design decisions, with syntax designed to be non-threatening to web ... designers who think HTML is a difficult programming language. ... Perl, Java, and other tools, and who has used it for at leat five ... CFMX is a wonderful little language for connecting to ...
    (comp.lang.perl.misc)
  • Re: Learning perl - for experienced programmers
    ... The books are cheap. ... They're more the "ease your way into programming and perl" type ... examples of hideous and unmaintainable Java code there's plenty I'm ... A language is only as bad as the ...
    (comp.lang.perl.misc)
  • Re: Need better string methods
    ... Language Reference Manual) on one of these languages, ... the Perl one liner sed/grep replacement is ... >Perl and can't believe that Python would be better. ... They are totally focused on circuit design, ...
    (comp.lang.python)
  • Re: Uniq from array ?
    ... does not prevent me from owning hard prints of the Cookbook, the Pocket Ref and recently Object Oriented Perl. ... It however prevents from owning 2 pcs of each of those not-so-slim books so I could equally easy refer to this or that at work and at home. ... I believe that Manning has also provided _Object-Oriented Perl_ in an electronic form that has been pirated on sites like this, but I haven't seen that one. ...
    (perl.beginners)
  • Re: ARC or ARCH ?
    ... >> were right to try to design a better language than Common Lisp. ... but Java didn't just associate itself with the Web. ... I would say Perl is better as a language than the shells, ...
    (comp.lang.lisp)