Inkwell: Authors and Artists

    
>>Why is HTML so writer-unfriendly?  It just turns all your careful
formatting
 into mush.


What does formatting have to do with being a writer (as opposed to a
publication designer)?
  

    
Well, for one thing, writers use indented paragraphs.

Poetry uses all kinds of strange and wonderful formatting.
  

    

Speaking of which, I need someone to help me figure out a web page.  Anyone?

Laura?
  

    
You mean you want to build one?
They're easy! Time consuming though.
  

    

I want to build one.  If I build it, they will come!
  

    
Or at least breathe hard.
  

    
Web pages can be as easy or as difficult as you choose to make them.

But if you want to do it yourself, as opposed to having someone else do it
for you, you obviously need to start with one of Laura's html books, as so
many others have done before.
  

    
Actually, I just built a web page and I don't know jack about HTML.  I used
PageMill, which I suppose you hard-core types would consider programming-on-
training-wheels, but by golly it works.
  

    

see, that's what I'm thinking.
  

    
I cannot read how-to books of any kind, particularly computer manuals. But I
found making web pages pretty easy, either with page mill or this goofball
program I use on my pc, "HotDog." It works just fine, regardless of whether
you know what you are doing. And, pretty soon, you know at least a little
bit.
  

    

You can even start by using the page composition stuff built in to your
netscape browser.  Or do the time honored thing of finding a simple page,
copying it, and pasting in your own words.

Of course a very intricate advanced html page design might have
intellectual property components.
  

    
The trouble with using PageMill or the like is such programs produce
unnecessarily complex and sometimes eccentric html. If it works, fine. If
something breaks, however, it can be damned hard to fix (or even
understand). Anyone here is capable of learning enough html in 24 hrs (let
alone Laura's canonical 21 days) to make a functional web page. On a scale
of difficulty of 1 to 10, html is no more than a 2.5.
  

    
Laura, I wonder if you've looked much at the other Perl books out 
there.  The Camel and Llama books (the O'Reilly books written by
Larry Wall, Randal Schwartz and Tom Christiansen) are sort of in a
class by themselves.  But there are lots of others on the market now,
of predictably varying quality.

If you'd rather not give an opinion of the other books, that's fine, I'm
just curious from a writing point of view whether you looked at any.

My friend Paul Hoffman (ex-<phoffman> on the Well) wrote the most
recent Perl for Dummies.  He wasn't real happy working with IDG,
I think.  The book is good but your comments about the marketing
approach are dead-on.  

For another insightful and necessarily wry view of computer book
publishing, see Phil Greenspun's outline of "dead trees publishing"
photo.net/wtr/dead-trees/story.html

If for no other reason than the part about "Why Computer Books Suck."

I hasten to add, not all computer books suck.  Right
there alongside the two Camel books (I've been using Perl since
1992 when there was only one Perl book to be had!) is my copy of
Teach Yourself Web Publishing With HTML 3.2 in 14 days, which is
simply excellent.
  

    
Most computer books suck. Almost all of the computer books by certain
publishers suck. Two of the three I wrote, if they don't actually suck, are,
at least not nearly as good as they ought to be, due to the constraints
imposed by the contracts.
  

    
Not sucking, then: just inhaling weakly
  

    

First: about HTML.  Despite the fact that I wrote a book about HTML,
I'm not convinced that these days most "normal" people need to be spending 
a lot of time learning it.  Yes, its easy.  Yes, you can pick it up in a 
matter of hours.  But with HTML tools like Home Site and Front Page and 
Composer et al, you can do perfectly good pages without mucking about with 
HTML at all.  The tools aren't *great* -- they generate funky HTML and tend 
to tie you to that one tool -- but they work OK.   Good enough for
government work.  
  

    


Re: other Perl books.  I have both the llama and camel books (both
editions of each one), as well as Advanced Perl Programming, the
Regular Expressions book, and the prior edition of Teach Yourself
Perl, the book I re-wrote.  I looked through the TOCs of a bunch of
other beginning Perl books in the store, but I couldn't name you any
names.  They were all really *really* basic, or seemed to effectively
ape the online documentation.  I hate that.  I don't think I looked at
Perl for Dummies, but to be honest, I can't remember.  Dummies books
are really in thier own category, almost.  People either love or hate
them.

Reading books on a topic when you're writing a book on a topic is a
bit of a double-edged sword: on the one hand, you're trying to learn
the topic and get an idea of what's out there in the marketplace; on
the other you don't want to get influenced by other people's work.
Before I did the Perl book this was an easy choice for me -- all the
topics I wrote about were too new to HAVE any books on the market, so
there were no books to read.  For the Perl book I tried to just get an
idea of what was out there, and focus my market reseach on the books
that I considered the competition.

For this book I assumed that my main competition was Learning Perl,
the llama book.  Its the book that everyone recommends for beginners,
supposedly the standard tutorial.  In fact, when my publisher
suggested I write this book, I said "why?  Learning Perl has that
market sewn up."  But when I looked more closely at learning Perl, and
talked to a bunch of people who had read it, I realized that learning
perl has problems: its a wonderful tutorial if you already know
programming and if you just want the basics of the language as fast as
possible with no fluff.  Its an o'reilly book in every sense of the
word: perl for geeks (that's not an insult).

But not everyone can learn from that sort of tutorial.  The main
complaint I kept hearing from people who wanted to learn perl, and who
had tried and failed with learning Perl, was that there wasn't enough
there, that it assumed too much programming background, and that it
was too Unix-centric (even the win32 version feels too unix-centric!).
In addition, I personally found the second edition to be not at all an
improvement over the first: the perl 5 features are tacked haphazardly
into the second edition, mostly into a single chapter that attempts to
explain modules, CGI and object oriented programming all at once
(eeek!).  It just doesn't work.

That's why I figured there was room in the market for my book, which
moves slower, has more examples, holds more hands.  The sorts of
people who like learning perl will detest my book.  That's fine.  Its
not for them.

Other books: Programming Perl is required reading, even if you have a
tutorial. Its the bible.  Mine is incredibly well worn (well, I also
dropped it in the hot tub once, which accelerated its wornness, but
its worn despite that).  I wish it was better organized.  I wish it at
least had a more detailed TOC; I have a hard time finding stuff that I
*know* is in there.

Advanced Perl is good, although it seems to me at least some of it is
not necessarily *useful* advanced Perl.  The regular expressions book
is godlike, although I worry for the mental state of its author.  When
I was writing the regex chapters of my book I became truly obsessive
and strange in a bad lovecraftian kind of way, dreaming in regex,
hallucinating in regex.  You are in a maze of twisty backtracks, all
alike.

I haven't read many of the newer ORA perl books.  Once I finished my
own book I had to take a perl break for a while.
  

    
> constraints imposed by the contracts

You mean like fast-as-you-can-type stream-of-consciousness composition, with
no time allowed for revision?

;-)
  

    
Well, that's an element. It's mostly "the clock starts ticking when they
ship you the beta version of the software" so you never have time to use the
actual shipping version in a real work situation because the book is
supposed to be on store shelves when the software ships. Most application
software books are written this way--they're called "day and date" books in
the trade.
  

    
On the other hand, you can take your time about it, do a
thorough treatment of the subject and get the publisher
mad at you because the ship date slips....  (I'll tell you
next year, whether this approach ever results in another
book contract.)
  

    
The regex thing is so right.  You start with a few backreferences and
pretty soon you're staring at issues having to do with whether the
system is NP-complete :)

(Answer: it is.)

I think your view of the O'Reilly books is quite right, Laura.  I'm not
really a programmer so some of it (particularly the references and
object-oriented stuff) just goes past me, but I had done a little bit
of BASIC programming and hung around C programmers for a long time,
so I found both Camel books to be invaluable, and I still refer to 
the first edition from time to time, tattered and torn as it may be
(actually, it looks like a well-used phone book).  

I never bought Learning Perl though I have skimmed through it at the
store a couple times.  The Dummies books are just, um, too dumb, 
I tried learning Tcl from the Dummies book and gave up in exasperation
(not to mention the fact that it was full of typos, bad code fragments
and every other editorial sin).  

In Larry Wall's notion of the ever-growing onion, the tools that work for
the inner layers of the onion (man pages for Tru Wizards, online help and
newsgroups for geeks, O'Reilly books for all of them and normal got-work-to-do
folks like me) aren't necessarily going to work well as the onion expands.
There are a ton of people out there doing things with Visual Basic and
Excel macros and all kinds of goop who need Perl, so I hope your book will
be a good entree for them.
  

    
 I eventually took my copy of Programming Perl, held the important
sections together, and colored little tabs on the sides of the pages
so that I can look at the book and know what I should open it up to.
It is also well bookmarked.
 
 (By the way, I'm jumping in here late, but I'd just like to say that
Laura's book is wonderful.  I'm a very experienced Perl programmer,
but I learned all sorts of things in the course of reading the book.
Disclaimer:  I was one of the tech editors of the book.)
  

    
Both my copies of the Camel book have post-it notes at specific spots.
I bet those of you who use them can guess pretty much where they are
(just one or two for each book).
  

    
 I have the reference of functions highlighted, and a post it note
where the file test switches are listed.
  

    
I generally only use it when I'm trying to figure out a regular expression.