A wide open niche in Perl publishing...

Discussion in 'Perl Misc' started by J Krugman, Feb 15, 2005.

  1. J Krugman

    J Krugman Guest

    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 know of only one such book, in any language. Its title is
    something like "C data base development", and it was written by Al
    Stevens. This book has been long out of print, but when I read it
    I thought it was great (even though at the time it was quite above
    my head). During the course of the book, the author implemented
    a simple DBMS in C, from scratch; all the code was provided and
    the discussion of the major design decisions was the meat of the
    book.

    I don't know why this sort of book is not more common. I realize
    that the market for beginners' books is much greater, but that
    can't be the only consideration for publishing a computer book,
    otherwise we'd never see books like "Advanced Perl Programming" or
    "Object Oriented Perl" or "Network Programming with Perl".

    I realize that it would be impossible to cover the design of a
    "real-world" DBMS (or text-editor, or web-browser, etc.) in a
    typically-sized book. By necessity, an application such as Stevens'
    C DBMS will have to be a bit of a toy. But these are toys with
    enough complexity in them to force the consideration of important
    software engineering issues (code organization, namespaces and
    nomenclature, error handling, performance vs. clarity and reuse
    potential), and in a concrete context with definite requirements,
    trade-offs, and consequences for the project at hand, as opposed
    to the stuff one often reads in hifallutin', airy-fairy theoretical
    discussions of best programming practices.

    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.
     
    J Krugman, Feb 15, 2005
    #1
    1. Advertising

  2. J Krugman

    Ted Zlatanov Guest

    On Tue, 15 Feb 2005, 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 know of only one such book, in any language. Its title is
    > something like "C data base development", and it was written by Al
    > Stevens. This book has been long out of print, but when I read it
    > I thought it was great (even though at the time it was quite above
    > my head). During the course of the book, the author implemented
    > a simple DBMS in C, from scratch; all the code was provided and
    > the discussion of the major design decisions was the meat of the
    > book.
    >
    > I don't know why this sort of book is not more common. I realize
    > that the market for beginners' books is much greater, but that
    > can't be the only consideration for publishing a computer book,
    > otherwise we'd never see books like "Advanced Perl Programming" or
    > "Object Oriented Perl" or "Network Programming with Perl".


    You can look at this series of articles (unsorted, start from chapter
    6) I wrote:

    http://www-128.ibm.com/developerwor...jsp?searchSite=dW&searchScope=dW&query=cfperl

    I explain the way I developed a pretty complex Perl application
    (cfperl) that uses Parse::RecDescent and many other useful modules and
    techniques. cfperl complements GNU cfengine, a system administration
    tool. I talk quite a bit about design issues, from the ground up.

    As to why this sort of book is not more common - it's not directly
    applicable to too many real-world situations, unlike reference or
    tutorial books, so there's a smaller audience, IMO.

    HTH
    Ted
     
    Ted Zlatanov, Feb 15, 2005
    #2
    1. Advertising

  3. 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. Not a single line of Perl in
    it, but still perfectly relevant for a Perl programmer who's designing a
    large-scale application using OOD.

    sherm--

    --
    Cocoa programming in Perl: http://camelbones.sourceforge.net
    Hire me! My resume: http://www.dot-app.org
     
    Sherm Pendley, Feb 15, 2005
    #3
  4. J Krugman

    J Krugman Guest

    In <> Sherm Pendley <> 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.
     
    J Krugman, Feb 16, 2005
    #4
  5. J Krugman

    Alan Mead Guest

    On Tue, 15 Feb 2005 15:04:30 +0000, 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 agree. I also agree that it's a Perl issue. Honestly, if you
    get a pattern book that is devoid of executable code then how much have
    you learned? And if an application book is written using PHP or C then
    you'll probably start using PHP or C. I think Perl could use more
    literature on this.

    But I don't think it is a complete vacuum.

    The book "Writing apache modules with Perl and C" has a fair discussion of
    authentication. A lot of people will tell you that authentication should
    be left to the server and this book is perfect for Perl programmers who
    are using Apache and who can control their webserver. If you get hosted
    somewhere (so you cannot load modules), this information is still somewhat
    helpful in creating application-level authentication. (Since creating
    sessions is a basic issue with any web application, authentication
    discussions are germane to all CGI applications, I think.)

    Then there is "Writing CGI Applications with Perl" which is the great book
    on this topic. The authors discuss a complete content management system
    and supply all the code. I seem to have lost my copy and I'm going to go
    buy another.

    Also, if you look at any of the framework-ish projects (e.g., Mason),
    they provide a model for applications. If those models work for you then
    you're time will be better spent learning to use them than re-creating the
    wheel. I've found that learning any one system takes quite a bit of time
    and energy and they all have purposes for which they are suited better or
    worse. Unless you can leverage someone else's work (e.g., "The
    competition is using Mason, so obviously we could as well") it's hard to
    shop around.

    I've considered trying to write something myself on this sort of topic
    with a slant towards people who collect data. You can see my latest
    creation at the link below. I thought I would describe my code in
    Schwartz's line-by-line style. Who knows if I will have the time...

    -Alan

    --
    Help out our research and get a free
    personality profile:
    http://www.web-data-collection.org
     
    Alan Mead, Feb 16, 2005
    #5
  6. J Krugman

    Guest

    Alan Mead wrote:

    > I've considered trying to write something myself on this sort of

    topic
    > with a slant towards people who collect data. You can see my latest
    > creation at the link below. I thought I would describe my code in
    > Schwartz's line-by-line style. Who knows if I will have the time...



    1) Reading books and usenet and practicing writing code is no
    substitute for getting a computer science degree and having years of
    experience in the industry. To make up for this, I am trying to learn
    the discipline of using as much of other people's code and as little of
    mine as possible. It has not been that easy.

    2) Books that make me follow the building of big programs with long,
    drawn out code examples put me to sleep. I also can't stand when they
    leave the code out because it's on the disk or online.

    3) Programming takes more time and effort than I thought it would when
    I first got started.

    4) Is it just me or do other people find Perl to be highly addictive,
    unlike any other computer language?

    5) Isn't it a scary thought that one individual human being created
    Perl? It seems like the Bachs and Mozarts of today are working on
    software and not music.

    6) I had a few more points but I forgot them. I need to go look at
    that Mason thing...

    wana
     
    , Feb 16, 2005
    #6
  7. J Krugman

    Peter Scott Guest

    In article <cuuja1$sjs$>,
    J Krugman <> writes:
    >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.)


    Heh. Well said. Developing something like, say, the
    aforementioned database application runs into so many real-world
    issues that force pragmatism to supersede idealism. Add in
    error checking, exception handling, logging, authentication,
    authorization, and other cross-cutting requirements and the
    beautiful patterns will be buried under a pile of... code.
    Waving a hand and mumbling, "Aspect-Oriented Programming" ain't
    good enough.

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


    Someone will.

    --
    Peter Scott
    http://www.perlmedic.com/
    http://www.perldebugged.com/
     
    Peter Scott, Feb 16, 2005
    #7
  8. J Krugman

    bill Guest

    In <cuuja1$sjs$> J Krugman <> writes:
    >(I sure hope that someone at O'Reilly, or Manning, or New Riders,
    >or Apress, etc. is reading this.)


    Pardon my cynical take, and since you bring up publishing
    and realism, vague pseudo-code books have a much broader
    potential market than brass-tacks, language-specific
    books. Maybe that's why "Design Patterns"'s Amazon.com
    sales rank is 853, while "The Perl Cookbook"'s is 1843.

    Maybe Joel Spolsky (who coined the term "architecture
    astronautics") is right in his claim that programming is
    something that most people can only learn through
    apprenticeship, not in school (and even less from books).
    The implication from this is that real-world programming
    is an activity dominated by issues that are too varied,
    too contingent, and too specific to be suitable for
    teaching grand theories in a university class (or for
    writing best-selling books about).

    bill
     
    bill, Feb 16, 2005
    #8
  9. >>>>> "b" == bill <> writes:

    b> Maybe Joel Spolsky (who coined the term "architecture
    b> astronautics") is right in his claim that programming is
    b> something that most people can only learn through
    b> apprenticeship, not in school (and even less from books). The
    b> implication from this is that real-world programming is an
    b> activity dominated by issues that are too varied, too
    b> contingent, and too specific to be suitable for teaching grand
    b> theories in a university class (or for writing best-selling
    b> books about).

    I don't really think that's the case. I think it's much more the case
    that *good* books about stuff at the brass-tacks level are extremely
    difficult to write well and extremely subject-specific. In
    particular, they don't appeal to managers who aren't up to their
    elbows in the material, and they don't appeal to novice programmers.
    There is no "Teach Yourself How To Write A Database In 24 Hours," and
    probably no market for it.

    (The only books I can think of that come close to being what you're
    talking about are _Advanced Programming in the Unix Environment_ and
    _Unix Network Programming_. Both contain a lot of information, from
    the theoretical to the gritty and practical.)

    I think Joel's idea is superfically attractive (like so many of his
    ideas are) because what is taught in university courses is computer
    science, where grand unified theories of everything are attractive and
    part of the discipline, and what is taught in the vast majority of
    books on bookstore shelves in the "computer" section is the rudiments
    of programming, which is far too basic for anyone who's actually
    working in the profession already. There's a giant
    software-engineering shaped hole there, and a real dearth of material
    aimed at people who already know how to program (and thus don't need
    to have the concepts of variables, objects, scoping, or loops
    explained to them for the fifteenth time) but who are looking for
    information on higher (or deeper) topics.

    When people eliminate the mystic folderol that claims that software
    engineering is essentially different from mechanical engineering or
    chemical engineering, and when software engineers are board-certified
    and are legally liable for their work just as professional engineers
    are, then this nonsense about how special writing software is will
    disappear.

    Charlton





    --
    cwilbur at chromatico dot net
    cwilbur at mac dot com
     
    Charlton Wilbur, Feb 17, 2005
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Web Developer

    char 8bit wide or 7bit wide in c++?

    Web Developer, Jul 31, 2003, in forum: C++
    Replies:
    2
    Views:
    595
    John Harrison
    Jul 31, 2003
  2. Cameron Laird
    Replies:
    3
    Views:
    394
    Fred Ma
    Apr 1, 2004
  3. Disc Magnet
    Replies:
    2
    Views:
    726
    Jukka K. Korpela
    May 15, 2010
  4. Disc Magnet
    Replies:
    2
    Views:
    800
    Neredbojias
    May 14, 2010
  5. Cameron Laird
    Replies:
    2
    Views:
    128
    Cameron Laird
    Apr 1, 2004
Loading...

Share This Page