A wide open niche in Perl publishing...

[J Krugman]

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

 

[Ted Zlatanov]

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

 

[Sherm Pendley]

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--

 

[J Krugman]

J Krugman wrote:

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

 

[Alan Mead]

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

 

[ioneabu]

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

 

[Peter Scott]

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.

 

[bill]

(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

 

[Charlton Wilbur]

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