PragDave

It means the money the publisher gets after the retailer takes their cut (which is usually 50%).

Generally speaking, tech publishers have a sausage factory-like production line books get pushed through. There's editors, designers, marketing, and acquisitions people involved in taking the author's manuscript through to a finished product, so that's where the money goes.

It also gets spent on all the dreck tech publishers (again, in general) pump out -- they work on a hits model, so they publish 20 books and hope one of them takes off. Their main function is to nag authors to get their work done.

I've heard "[book] publishing is broken" over and again, and it's true. Tech publishers only pay peanuts, so authors get pushed to finish the book quickly (if they start at all), so the quality isn't very good, so people don't buy many books, so tech publishers can only afford to pay peanuts...

Sadly, not much has changed for the major tech publishers since the late 90s at least, when Philip Greenspun wrote about his experience in 1997: http://philip.greenspun.com/wtr/dead-trees/story

That said, there are publishers which give their authors a better deal -- Pragmatic Programmers for one (which Peter Cooper discusses -- see link in his comment), who pay 50% as discussed here: http://pragdave.blogs.pragprog.com/pragdave/2009/10/pragmatic-bookshelf-royalty-rates.html . They may not do the same volume as the majors, but I doubt it's 5x less.
Anyway, I agree it would be more healthy…

Awesome! I was looking for this article about 12 months ago. Still just as useful to know today as it was then.

For anyone who doesn't already know this inside and out, the tl;dr spoiler: the surprises are that procs do not even care how many arguments they are passed, and that they can return on behalf of the function in which they are executed.

Compared to lambdas, which spew runtime errors if they don't get the right number of arguments passed in, and which always return control to the line after where they were executed, regardless of whether the return keyword is used.

I'm reminded of the Dave Thomas pipelines using fibers series of articles. I'll just leave this here:

http://pragdave.blogs.pragprog.com/pragdave/2007/12/pipelines-using.html
http://pragdave.blogs.pragprog.com/pragdave/2008/01/pipelines-using.html

DSL's are great as long as you don't take them too far towards the "natural language" style of coding.

For example, I find RSpec's story runner uncomfortable to work with because of the overly English-like syntax it uses.

This blog post has some "before and after" code showing the same tests/specs implemented at unit tests, and as Rspec stories:

http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runner

To me the heavily DSL-oriented story code is easier to read as far as intent, but as a programmer trying to figure out what the code is actually doing, it's sort of a big WTF.

Dave Thomas has an interesting writeup on "DSL's going too far" at:

http://pragdave.blogs.pragprog.com/pragdave/2008/03/the-language-in.html

It's very true. And if you decide to fork it
than that's what you hear: "OMG, YOU CAN'T
FORK RUBY. ARE YOU CRAZY? THAT WOULD BE TERRIBLE."

Or not:

http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-rubymy-rubyconf-keynote-is-now-up.html