Slashdot Mirror

> ANTLR, which is a far superior alternative to lex/flex yacc/bison IMHO.

Another alternative is JavaCC, which (shameless plug!) I document in great detail in my book Generating Parsers with JavaCC.

...on the post is pretty interesting. Here's an excerpt:

If you were to self-publish, you will find that you might print, say, 1000 copies at $8 each, or 2000 copies at maybe $6 each. (It could be more. I'm not as close to book printing prices as I used to be.) So you're out $8-$12000 up front. So lets say you've guessed exactly right how many copies you will sell. You printed 1000 copies for $8K, and sold all 1000 for $30K to $40K (depending on where you set the price.) You made $22K, or maybe even $32K, versus the $19K you earned with APress.

He goes on to discuss the hassle of shipping, returns, credit card processing, storing the books, etc. All true, all good stuff.

For what it's worth, going through a small local publisher with my JavaCC book has worked out pretty well. We did a much smaller print run - 350 books - so the storage wasn't as much of a hassle. Definitely a niche market, though.

When I was working on my JavaCC book I bought Jukka Korpela's Unicode Explained and it was *extremely* helpful. After reading it I actually felt comfortable using various tools to convert from one encoding to another, discussing multibyte character sets, and so forth. It helped me write the Unicode chapter in my book with some confidence. It was the first time I had used vi to enter Unicode characters... fun times.

That said, it sounds like "CJKV Information Processing" covers some of the same ground. Has anyone read both?

...on the JavaPosse Google group here. Some talk about what this might mean for Netbeans, as one of the JavaPosse guys (Tor Norbye) is (was?) on the NB team.

Also, what would this do for the massive JavaCC book market? Expand it, I hope!

> you could write it in Notepad or vi for all that it matters

Yup. I wrote my JavaCC book using vi + dbhelper.vim, DocBook, and a few little Ruby scripts to run all the example code. It's nice to be able to regenerate all the examples with a nicer format in 3-4 minutes or so. Good stuff.

> FOP - Use XSL-FO to design printable page layouts in XML,
> then use FOP to transform them to PDF documents.

Right on. I used Docbook + FOP to write my JavaCC book; FOP held up fine for most things. It had some problems with (as I recall) callouts and footnotes, though, so, I did the final version with AltSoft's XML2PDF.

Speaking of which, if you're writing a lot of DocBook, Bob Stayton's Docbook XSL is indispensible. I bought the third edition and you can tell that he monitors the mailing list closely; he answers a lot of common questions.

> Many times I have edited lex and yacc code, but
> never have I understood what the hell I was doing.

So true. I'm writing a JavaCC book and I'm still learning new stuff about it even though I'm almost done with the book.

The thing that's worked best for me is writing the lexical spec first, then going back and writing the parser spec. At least then you know that the basic tokens of the language are being recognized before you try to shape them into a parse tree.

> Text (ascii, if you will), is the lowest
> common denominator for people and computers.

So true. Although I'd even add the HTML Unicode escapes to that definition of text. I'm working on a JavaCC book right now and writing it in DocBook, and you can easily do Unicode characters with the hex encoding. For example, ü (or U+00FC) is ü. DocBook handles this just fine, the PDF output looks good, and so the book can use accented characters and such when appropriate.

> a few hundred copies per year.

Exactly right. I expect my JavaCC book to sell about that - maybe - each year. But since it's published by a small outfit, that's OK. We'll sell ~60 copies, break even, and consider the rest gravy.

I'm slowly working my way through it; it's a great book on a number of levels. The writing itself is very nice, with a real personality showing through and not just the usual dry technical flavor. The illustrations are done in a nifty "drawing" style that looks good and portrays the data well. The technical insights are very helpful; after reading what I've moved through so far I've rewritten some of my Rails code to be more efficient.

I highly recommend this book; the $40 you'll spend on it will be repaid the first time you delete a swath of Java looping code and replace it with an additional subquery. If I can do half as well on my next book I'll consider it a job well done.