3 ms·
While this looks impressive, I think "programming a book" is still too tricky for authors. Repeating syntax and formatting books is hard, but authors struggle
by ztratar 7y ago
While this looks impressive, I think "programming a book" is still too tricky for authors.
Repeating syntax and formatting books is hard, but authors struggle the most with writers block, creating stories, sourcing content for nonfiction, etc. Once much of this hard work is done, a lot of the good ones will partially hand off formatting to an editor/publisher. Of course they'll work closely with them, but whether that work is done in MS Word vs a Programming language is the secondary.
The majority of these docs are clearly aimed at programmers who are interested in MB's though process and why the data model is clean, as opposed to what life of an average author (or best-selling author) looks like, and how the tools will help them write better books.
Wishing the best for this project. Perhaps a version of it could be sold to publishers?
- taneq 7y agoI wouldn't even necessarily say it's "too tricky", just that it's not something that they probably want to be doing (computer scientists aside). If they'd wanted to code, they'd be coders, not authors. I'd be perfectly capable of writing and typesetting a book, but would I want to? Hell nah. So I'd expect the same is true of authors.
- TheOtherHobbes 7y agoNo non-developer author or editor is going to look at this and think "Wow, that is amazing. This is the future of publishing." And I wouldn't bet on unquestioning support from developer authors/editors either. To be harsh, this is one of those projects where someone who doesn't understand how key parts of an industry work has decided that their "I made a command-line content build system in $interesting_language!" solution is superior to absolutely everything that already exists - based solely on their own opinion. Professional peer review would not be kind about this.
- chipotle_coyote 7y agoAs someone who does understand how key parts of an industry (i.e., publishing) work, authors broadly fall into one of two camps: (1) Authors who let other people do all the "non-writing" work, whether via traditional publishing or, if they're self-publishing, paying contractors to do that work. This is both editorial work and, most important for this discussion, layout work. These folks aren't going to use Pollen, but a vanishingly small number of them are going to use anything but a standard word processor. If they get nerdy, they're getting nerdy with Scrivener. (2) Authors who, for whatever reason, do in fact want to do the layout work themselves. (That group can be subdivided into "people capable of doing the layout" and "people who believe they are capable of doing the layout but really aren't.") They're going to use whatever the hell they feel like using, within whatever constraints are set by whoever they're working with. In either case, whoever is doing the actual layout is doing it with actual layout tools: at most non-technical publishers this is going to be Adobe InDesign or Quark Xpress; at tech publishers it's at least as likely to be Framemaker. (In my observations LaTeX rarely shows up unless the author is in the "do the layout myself" group.) In either case, Pollen is aimed at the people doing the layout. And, since you like being harsh, there's no indication you put the least bit of effort into understanding what Pollen's author understands about publishing, typesetting, or anything else. There are valid criticisms to be made of Pollen, starting with the premise that books "on the web" are something that the majority of readers actually want (and the corollary assumptions like "ebook readers can't do as good a job," which is true only to the degree that current ebook readers/creation software can't do so), but "this guy has no idea what he's talking about, he just wanted to write a command line app in Racket" is not one of them.