Blunt and necessary review of programming language books. | Hacker News Reader

Blunt and necessary review of programming language books.

drdobbs.com

200 pointsthewonggei109 comments

I'd been meaning to pick up a new language, and a few weeks ago I pared down my list of choices to two languages: Scala and Go. Then I went looking for "official" tutorials/references. For Scala I found Scala by Example, a 145 page PDF that comes with the Scala docs. For Go, I found the Go tutorial -- a very short tutorial with a bunch of examples.

I picked Go because, seriously, I don't have time to read 145 pages just to get started. I'd be fine if Scala By Example introduced me to the major features of the language in a single whirlwind tour so I could at least start solving simple algorithmic problems, but the Scala folks went for something more elaborate. If it works for them, cool.

Ever read the Python tutorial? Even though it omits a bunch of important stuff, like decorators, it gives you enough information to get started with the language. A more dedicated learner can just read the PEPs or the language reference to learn about advanced features as he needs.

This is what I do with Go these days: look up features I'm having trouble with in the reference.

A friend once said this: "I'm convinced that in reality the documentation is the product."

The first chapter of K&R is a tutorial introduction, it explains the entire workings of the C language for someone familiar to programming in a small number of pages(It misses pointers, but it covers a lot).

Every book on a language needs this. The best I have seen was in a python book where the author stopped and told the reader enough had been learnt to write any program. The closet to the K&R model I have seen is with the Big Nerd Ranch books.

<quote>The best I have seen was in a python book where the author stopped and told the reader enough had been learnt to write any program.</quote> You must be referring to Think Python: http://www.greenteapress.com/thinkpython/thinkpython.html

Think Python is a fantastic intro-programming text. After mucking about with bits of code for a couple of years, I picked up Downey's previous version of the book, and that's when I became a programmer.

I highly recommend it to the handful of HN readers who are in need of an intro text.

It's a model that I followed when I wrote Hello Python. The theory being that the way that most of the good programmers that I know learned was by extending their knowledge, not by inhaling massive chunks of information.

I'm now reading K&R, and I'm surprised at the similarities, although I introduced new libraries just as much as new language features.

Every time I try to learn Scala I get the feeling that it's too big.

It's definitely not the kind of language that you spend a few weeks or months with to learn a few new concepts. It's a language you learn because you can see yourself doing a lot of real programming in it. I call it the C++ of the Java world, meaning that Scala is to Java as C++ is to C: a more complex and expressive language that piggybacks on top of a hugely successful ecosystem and is a powerful tool for those who invest the time to learn it well. I'm learning it because I think it has a bright future in commercial software development, and it's nicer to work with than most languages that can say that.

It struck me the other day that I would love a "Scala: The Good Parts". Wouldn't it be great if there was a small, powerful kernel in there, somewhere, and someone explained it...

While definitely not small, the stairway book, "Programming in Scala" by Odersky, mentioned in the article, is an excellent tutorial style book. The second edition was just released in January.

Even if there were such a book, you'd have to deal with other people's code that used the "Bad Parts" of Scala. I dread deciphering clever Scala one-liners.

Had the same issue, same two languages. Google Go still feels far from prime time, so I settled on Scala.

Got David Pollak's "Beginning Scala" book, Googled a lot and after several days of coding it clicked. Well worth the effort! The Web frameworks are not yet there (Lift is complex, Play is slow), but I learnt a lot.

I still keep my eye on Go, code most of the time C++/C++0x, some projects in Scala, and hope one day I can have all the benefits in one place.

Google research got to the same conclusion: http://www.theregister.co.uk/2011/06/03/google_paper_on_cplu...

+1 to Go. I am not aware of any books on it. But between the spec, Effective Go, and the tutorial you can learn the entire language in a matter of days if you have serious project you want to work on.

I'm the exact opposite. I hate to "tinker" around with languages or frameworks. I hate the feeling of not knowing what I'm doing and have to google for every bit of progress.

I think this is where modern trends in programming language books, and by extension language learners who enable these books, gets it wrong. Everyone is trying to teach you the bare minimum to get started, and they leave you to struggle with the rest. This is a big reason why there are so many programmers who barely know anything below the surface of the language they've been using for years.

I like taking a fairly broad tour of a language before digging in. I like knowing what the essence of the language is. I like knowing whats possible and what isn't. I hate the feeling of being blind, feeling around the room for the door knob to get me into the next room where the process is repeated.

> I picked Go because, seriously, I don't have time to read 145 pages just to get started.

You don't need to read 145 pages to get started. Most people I've talked to only know 20-30% of Scala. But they feel that they already know enough to benefit enormously. Most of the Scala I know comes from the Tour of Scala, which consists of succinct, bite-size explanations of its main features.

On a related note, Scala is a big language because it is a dual language: It has features that are intended to facilitate application development, but it also has features that are intended for framework writers. These features are overkill for you if you're an application writer, and you don't have to learn them, but they are a godsend if you're writing a framework. This is evidenced by the fact that many features that are traditionally done in the compiler of other languages are implemented in the library!

IMO, Scala is a tasteful collection of the best features from a bunch of different languages, including ML, Haskell, Smalltalk, and Clojure. [1] If I taught a survey course of programming language features, such as Stanford's CS 242, Scala is the language I would use to teach it.

[1] And they are not transplanted unmodified; often, since Scala has the advantage of hindsight, they are often modified to be even better!

I also didn't like the verbosity of intro-level books/tutorials and decided to write my own for Python:

http://www.korokithakis.net/tutorials/python/

It introduces most features of the language over 10ish pages, but assumes that you're familiar with programming.

I agree 100%. K&R is the standard all authors should strive for. The length of these books is also our fault. Bigger books sell better. I hope there is a backlash brewing. K&R, Little Schemer, Smalltalk Best Practice Patterns, were all great small books.

    Bigger books sell better.

Is this true? I was always under the impression that bigness was used to justify a higher price point.

I suspect it's a perception issue... the price difference between a slim programming book and a fat one is minimal. Dropping $50-$60 on a tome feels like a better value if you have to wheel it out with a dolly, instead of slipping it in your pocket.

I have to concur, unfortunately. If a tutorial book adds a huge reference section, I'd feel that it's a better deal for the same price- I may never look at the appendices, but I'll feel that I possibly could, just in case. Publishers ought to fix the pricing in general.

regardless of whether it's true, greenspun reported that it's what the publishers believe:

"It is an article of faith in the computer publishing that bigger books sell better. They take up more space on the shelf and readers with a tech problem find a bigger book comforting. Readers aren't really sure what is wrong with their computer and they only have a few minutes in the bookstore so they figure the thickest book is the most likely to contain the solution."

http://philip.greenspun.com/wtr/dead-trees/story

Its absolutely true. The exact same effect occurs in restaurants and floral arrangements.

There is a fixed cost, we'll call it X, to get the {book/meal/arrangement) made, the marginal cost of {paper/food/flowers) is small relative to the fixed cost and yet is the dominant factor in perceived value.

Understanding this you can use it to your advantage. You can boost the percieved value of a book or meal or floral arrangement by boosting its pages, vegetables, or flowers. The recipient will feel better about getting and the buyer will feel better about paying for something with a higher perceived value.

Wow, great answer. I would love to read more about the psychology of this. Does it differ across cultures?

Also consider that on a bookstore shelf, the bigger the book is, the more space it has to advertise itself. It is its own advertisement.

I cannot speak to the accuracy of sales vs size, but I wholeheartedly support smaller, better books. I have seen this same trend in textbooks, and it's maddening. Nobody can work through an 800-page textbook on one semester, and it's easy to get the feeling that most of these are exhaustive for their own sake.

Smaller, better books please. I have been, and will continue to, vote with my wallet.

Agreed. Obviously K&R is a benchmark. But I'm also thinking of "Effective C++". This was a fairly thin book, but after reading it, I realized that I didn't know half as much about C++ as I thought I did, and in its relatively small number of pages, it taught me a hugely disproportionate amount of how C++ really works.

"Accelerated C++" is another good one. A bigger book than K&R, but not outrageously so, and much thinner than Stroustrup's or Lippman's texts. Rather than teaching C and then layering C++ constructs on top, it starts with idiomatic C++, then drills down to the C foundations as needed.

I love the format of the whole "Effective ..." series, especially the fact that the books are focused on best practices instead of individual language features.

I found Little Schemer to be too elementary. I feel comfortable with lexical scoping and recursion, I was actually looking for more meat (let vs. let* vs. letrec). I'd recommend "Teach Yourself Scheme in Fixnum Days".

_The Scheme Programming Language_ by Kent Dybvig is also very good. _Structure and Interpretation of Computer Programs_ is my preferred "how to think in Scheme" book. I would recommend against _How to Design Programs_, which is entirely too pandering and focused on imperative programming for my tastes.

http://www.scheme.com/tspl3/

It seems there's a fourth edition:

http://www.scheme.com/tspl4/

Also, Wikipedia says that "Teach Yourself Scheme in Fixnum Days" is outdated in some parts:

http://en.wikipedia.org/wiki/Teach_Yourself_Scheme_in_Fixnum...

TSPL4 covers RSR6 which didn't go over very well with the community. TSPL3 is probably the better bet there.

For what it's worth, the second edition of How To Design Programs drops the imperative programming[1] and is available online[2].

I can't comment about the pandering though.

[1] "This edition of the book drops the design of imperative programs. The old chapters remain available on-line"

[2] http://www.ccs.neu.edu/home/matthias/HtDP2e/Draft/index.html

Is that just the first few chapters of the 2nd ed?

http://www.ccs.neu.edu/home/matthias/HtDP2e/Draft/i1-2.html

Many chapters after that one are just blank.

Yeah, I'm not sure. That's the "unstable" version, and it looks like some of the chapter's are missing (everything after part 6).

'The Little Schemer' is not intended to be a tutorial on Scheme. To quote the preface, "The goal of this book is to teach the reader to think recursively". Similarly, the other books in the series have well-defined goals.

Did you take a look at The Seasoned Schemer, the sequel to the Little Schemer? It might have been better suited to you.

I tried to learn programming but I was discouraged by the utter lack of pedagogy in the books I've picked so far. The author pretty much nailed it.

I even tried Land of Lisp only because it was supposed to be fun, but unfortunately it used this horrible and widespread format where the author writes all the code for you and proceeds to an explanation.

There is no creation (or creative problem solving) ! And creation is the fun component, it should be the point of programming.

Later, I read the Little Schemer and I found it very fun and engaging. Because I had to think by myself, I realized I learned more in 30 minutes with the Little Schemer than 200 pages of Land of Lisp.

My first attempt at programming was with an horribly dull PHP book. 5 stars on Amazon, but it was again the same format where the author writes all the code for you and then explains it, and did not provide any exercise.

I think the perfect programming book would be a mix of the Little Schemer and K&R : the quiz format for the theory coupled with challenging exercises. There is no greater reward and way to learn than solving problems by yourself.

Personally I cannot learn from a book where I am just given concepts and supposed to find a solution. I find reading other code to be a much better learning method.

I have seen most students prefer to presented with a whole working program and then expand on it in the challenges the book provides. The author of this article was expressing a desire for shorter books that give full code listings rather than code snippets and challenges that you seem to prefer.

For challenging Scheme exercises, check out the sample programming assignments for SICP: http://mitpress.mit.edu/sicp/psets/index.html

SICP itself (http://mitpress.mit.edu/sicp/) is worth checking out, too. I doubt you would find the book itself to your taste, but there are programming exercises at the end of each section.

Also, for what it's worth, my favorite language for working Project Euler problems is Scheme, by far.

I might never write another line of C in my life, but the K&R book will always have a place on my shelf due to many of the reasons given by the article's author. _The Unix Programming Environment_ and _The Practice of Programming_ are two other books that serve as inspirations, both as a writer and a programmer.

The common element here is Brian Kernighan. _The Awk Programming Language_ is excellent, too.

One of the points of unappreciated genius of C is that when I used it as a reference, the example code often had something to do with the issue that I was currently facing.

It was if those guys had used the language for a few years building a diversity of things with it; kept notes; and then really thought about the future reader. I'd have thought that it was a revolutionary approach, not a historical oddity.

It was if those guys had used the language for a few years

I hope that's a joke. If you don't know who K and R are, and where they wrote the book, you should look it up.

I've been begging publishers to let me have a go at a ~100 page F# tutorial book, but they've told me again and again that books without a wide enough profile on the shelf just won't sell.

It's sad really. I hope ePublishing fixes this.

It's not worth the trouble to go through a publisher anymore. You're not going to make any money on a tech book no matter how popular it is. The smart move in the modern age is to work on the book in the open with a blog and then self publish an ebook. If you like you can even sell it or ask for donations.

I'm starting to think that the ransom model is the wave of the future for self-publishing. If it can work for small-time written works publicized online like role-playing games, what about other kinds of books: http://en.wikipedia.org/wiki/Threshold_pledge_system

Think of it- if publishers won't agree, bypass them and drum up support by getting enough pledgers to prove them wrong. Then self-publish and have the last laugh.

The combination of kickstarter-like funding models complemented by transparent incremental development models (i.e. blog as you go to increase interest, release the finished product later, or construct a finished product from organic blog posts) certainly lowers the threshold substantially. More so, it increases the strength of monetary feedback to a degree that it becomes much more financially viable for writers to make a living off their works, especially for technical non-fiction. I'm very excited to see the tranformation of the writing profession that is upon us.

Write the book. Show it to HN. People will buy it!

Start a project on Kickstarter and post on HN. http://www.kickstarter.com/

If you can put together a $30 F# book at 100 pages, I would consider buying it.

There are a number of self-publishing options out there, I believe. Let Over Lambda is a Lulu print, I believe.

I am sure that you could find someone to serve as editor for the book as well.

(there's a consulting idea: book editor! )

Thanks. I'll think hard about doing this and see what happens.

Check these guys out. They're trying new model book publishing, too.

http://www.unbound.co.uk/

So the blame is not really on the publishers, but rather on the average programmer who will choose books based on how verbose they are.

Part of this stems from a pre-internet mentality. "Of course I need a full function reference! Where else would I find it?" Now you just Google it. A thinner book can leave the reference to the search engines, but for some reason this older way has become entrenched.

I agree, although I still like having a hard copy reference. The biggest problem is that books are harder to keep current.

Yeah. You can't write "THIS PAGE IS ALL LIES" on a webpage, but it's easy and helpful in a book.

Yes, but that attitude is not dead: how many projects have you come across where the only documentation is the JavaDoc or equivalent? It allows someone to tick the box that yes the documentation is done, with minimal effort, but it's not that useful to the next programmer, who really needs sample code, oh, I get this from that, and this from there, then I feed them both to the function...

JavaDoc can be good, there's nothing to stop you including short usage examples for a class. Not that it's that common...

You had man pages, which are as good if not better than what you might find on Google. If you were writing C programs on a UNIX system, everything you needed was there. No need for K&R to kill trees putting all that in their book.

His point about JavaScript is great. Based on Amazon reviews, I couldn't find a single concise tutorial book for beginners from any of the major publishers. I finally bit the bullet and bought the paperback version of Eloquent Javascript (http://eloquentjavascript.net/) which is not only updated compared to the site, but looks to be very promising in terms of brevity and emphasizing hands-on portions. If I wanted a reference guide I have my copy of JavaScript: The Good Parts.

So aside from K&R, what are some of the best small books?

"Programming in Lua" by Roberto Ierusalimschy ( http://www.inf.puc-rio.br/~roberto/pil2/ ) is an absolute gem, in my opinion.

The Little Schemer (196 pages) Programming in Haskell (171 pages) are two that spring to mind.

Expert C Programming, Deep C Secrets by van der Linden (everybody just has to buy this book, even if you're not doing any programming. The jokes and the anecdotes are alone worth it.

I liked most books from Addison Wesley's C++ In Depth Series edited by Stroustrup, they are all thin (around ~300 pages), esp. Exceptional C++.

Just Java by the same Peter van der Linden was also quite good humor-wise, although I haven't read it in years (it was released around the same time as the first JDK). It's significantly thicker, though, since it covers a broader range of topics like networking and GUIs.

The best of the humor is contained in sidebars dubbed "light relief"; I seem to remember a passage indicating the author was not invited to write a specification because the other authors "didn't want any light relief in it" or something to that effect.

I really enjoyed O'Reilly's compact "Up and Running with Rails," which I bought because I could never remember the basics after two reads through the default (monster) rails book, "Agile Web Development with Rails."

Sadly, O'Reilly appears to have lost interest in this series; the Rails book dates to 2006 and is too far behind now to recommend. Look no farther than the #2 rated Amazon review ("28 of 29 people found the following review helpful") to find out why: "Given that this book is only 127 pages long without the Appendix, it's a pretty pricey little item.... a $29.99 retail price seems exorbitant... this little book would make a great introduction to a more comprehensive book on Rails. Stand-alone, it feels like a rip-off."

I was also going to recommend "Effective Perl Programming" -- but now I see that the second edition has been bulked up to 500 pages from the original ~200. Ugh.

Yes, that attitude seems fairly prevalent. I read a lot of Amazon reviews suggesting the same idea, that you should basically be paying by the number of pages. What that fails to acknowledge is that distilling ideas down to just the important parts is hard work. It's possible that a short book doesn't cover the topic very well, but I think it's more likely that the author has worked really hard to express their ideas in the fewest number of pages possible.

Lately I have decided that I won't even buy computer books that are more than ~300 pages, and I would prefer if they were more in the 100 to 200 page range. I'll take a short, concise, highly target book over a thousand page monster any day. And I'm more than willing to pay "full price" for the short book.

"Modern Perl".

Well written, covers pretty much everything you should use, good, clear examples.

Available free online: http://onyxneon.com/books/modern_perl/

"Smalltalk Best Practice Patterns" by Kent Beck (240 pages). K&R weighs in at 274 pages.

Manning's books are all quite concise.

O'Reilly Pocket References. They're not tutorials, but they sure are handy (and cheap).

Roberto Ierusalimschy's Programming in Lua[1] comes to mind. (The link is to the freely available first edition. There's a second edition available that covers more recent versions of Lua.) (Whoops - apologies to brianm - he beat me to this, but I didn't notice.)

Maybe also Graham Hutton's Programming in Haskell[2]. It's certainly wonderfully concise and dense (you meet a simple Haskell quicksort in the second chapter, as I recall), but I have to admit that I haven't had a chance to finish it.

One more: The AWK Programming Language[3] by Alfred V. Aho, Brian W. Kernighan, and Peter J. Weinberger, but that's almost cheating since one of the authors is K from K&R.

[1] http://www.lua.org/pil/

[2] http://www.cs.nott.ac.uk/~gmh/book.html

[3] http://cm.bell-labs.com/cm/cs/awkbook/

"Introduction to the Theory of Computation" by Michael Sipser. Was the only computing text I enjoyed reading at university. Sipser explains difficult concepts in a concise and easy to understand way.

Two of my favorites in the "best small books" area are from Niklaus Wirth:

- NW: Algorithms and Datastructures. 179 pages. PDF: http://www-old.oberon.ethz.ch/WirthPubl/AD.pdf

- NW: Compiler Construction. 131 pages. PDF: http://www-old.oberon.ethz.ch/WirthPubl/CBEAll.pdf

Both books are really brilliant and it always fascinates me how much content he packs into the books. Highly recommended. (I like "Project Oberon" too, but it has probably too many pages for this category [>400].)

Accelerated C++ by Koenig and Moo

pg's "On Lisp" is probably the book that has expanded my mind the most, and it's pretty short: http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf

After K&R, it was 'Using C on the Unix System' by Dave Curry (~200+ pages).

I also enjoyed the first edition of Learning Perl by Randall Schwartz (~200+ pages). This book introduced me to regular expressions.

Although probably outdated by now, I learnt Java from a book called "Java a Practical Guide for Programmers" by Sikora. When most Java books weighed in at a 1000 pages it was incredibly refreshing to find one that was 170 pages and assumed you already knew how to program.

I thought that Armstrong's _Programming Erlang_ was the best intro-to-a-language book I'd read since K-and-R.

I'm working through Erlang and OTP in Action (Manning) and while it's not as concise as K&R it's doesn't strike me as having been gratuitously bulked up at all.

Effective Java is the best book for general Java that I know - http://www.amazon.com/Effective-Java-Programming-Language-Gu... It's not a tutorial, but a collection of recommendations that could take you from just-learnt to competent.

Very slim, and very good - Javascript: The Good Parts http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

For a C reference, Harbison & Steele is excellent - http://www.amazon.com/Reference-Manual-Samuel-P-Harbison/dp/...

I don't know Harbison & Steele, but both Effective Java and Javascript: The Good Parts are really excellent. Worth noting that they're both really only about the language, not the accompanying libraries/environments.

H&S is what I thought K&R would be, but wasn't. It's an obsessively detailed description of the C language and standard libraries, in readable english, that describes everything from "traditional C" through ISO, to C++ compatible. When I'm working in C I use it as much as I use man pages, to help me keep the code as standard and cross-platform as possible.

"Steele" is Guy Steele, btw - http://en.wikipedia.org/wiki/Guy_L._Steele,_Jr. (author of "Common Lisp, The Language", developer of Fortress, etc etc).

I always loved The Perl Cookbook. It's got some in-depth discussion in there about language features, but most of the time what I want from a language book is a bunch of (complete) examples to help me learn the syntax, and probably to show me what the language's benefit is.

Thanks!

A further point is that digital distribution does NOT relieve the author of the responsibility to pare down a book. An 1800 page PDF is just as bulky and opaque as an 1800 page book, even though I don't have to lug the PDF around with me.

In the long run (and often even in the beginning) I find well-written, well-organized reference material to be more useful than a tutorial guide.

I did not use Lutz to learn python, for example, I used David Beazley's Python Essential Reference. He includes a brief tutorial of the implementation and basic language features and moves to a large selection of the python standard library. My favorite C book is the reference by Harbison and Steele, which is a careful, thorough, and detailed reference of the language features and some of the standard library.

I never understood why would anybody want a bulky reference book describing the standard library, when they same information – only more up-to-date and searchable – can be found online.

I have the Java book -- tome -- he talks about, and completely agree. I purchased it years ago when I was first learning the language, and after attempting to slough through it I wound up giving up.

It has been my experience that the books I get the most out of are the more concise ones. There appears to be a negative correlation between the size of a programming book and its actual usefulness.

It might be better now than since I last looked, but the one language I haven't found a good tutorial for is Haskell.

All the ones I've seen either dumb things down way too much with cartoons and such until they're difficult to slog through and pick out the relevant info, or they assume the reader either already has a working knowledge of Haskell syntax or a working knowledge of group theory.

I found 'Learn you a Haskell for great good' (http://learnyouahaskell.com/) excellent. It does not depend on the cutesy cartoons and nothing is dumbed down. I think it does not suffer from the criticism levelled in this article: it has plenty of code in the introductory chapters. Not 20 lines, but that's because fewer lines are needed.

Anyone know of the equivalent of Stroustrup for Python? If anyone's not familiar with Stroustrup, his book on C++ explains the language in-depth, and gives clear rationales for the design decisions made, so you understand not just the hows but also the whys. It's not a reference manual -- it emphasizes depth over breadth -- but it's also not a tutorial.

Publishers that I have learnt to avoid (overly verbose, code snippets instead of working programs.

Addison Wesley

Appress

O'Reilly(cookbooks fare better)

just dropping my two cents, I did not enjoy the pick axe, and when I turned to learn erlang I was essentially weighing two options: Pragmatic Bookshelf's erlang book and O'Reilly Media's erlang book. I chose O'Reilly's because I didn't want a long winded tutorial, I want the feature list gradually shown to me in order of complexity so I can jump into my own project without having to build the outlined in a book. The C++ langauge tutorial on cplusplus.com is also written this way, it presents the language's funtionalities in order of complexity.

I found it worthwhile to read the erlang books concurrently. Other than a few misalignments, they present topics in roughly the same order, but the way they explained the different topics were different enough that I found myself learning something new.

how ironic that you would read 2 erlang books concurrently.

EDIT: Duh! His email is at the bottom of the article. Oof.

How can I get in touch with Andrew Binstock? (The author of this wonderful article.)

Programming Perl is definitely guilty of this.

Is it supposed to be a tutorial book? I always thought that it was trying (and epically succeeding) to be a massive reference.

I know O'Reilly has the llama and alpacas that are intended to be the actual tutorials, though I can't really speak for their quality (I actually did learn Perl via Camel Book + external projects).

Masterzora,

Correct. Programming Perl is not meant to be a tutorial. That role is filed by the most excellent O'Reily Book "Learning Perl."*

* My first scripts were done using Learning Perl as my tutorial. It is still one of my favorite programming books.

I'd say it's somewhere in between; it starts with a single-chapter overview that shows enough Perl that you can start writing programs, and there's definitely a progression through the chapters, but it's also got a pretty thorough coverage of the whole language (at the time of writing).

I learned Perl by reading Learning Perl, but even trying to use Programming Perl as a reference since then has been difficult for me. The book is conversational and humorous in its tone, which makes it extremely verbose and irritating to read when I'm actually trying to get information out of it. There's too much raw text and not enough examples, particularly when it comes to syntax. I also find that because the book attempts to be a complete reference, and because Perl at its core is insanely complicated, Programming Perl (like the Perl online documentation) spends far too much time dwelling on minor technical details and edge cases which no sane coder should ever be thinking about using.

Too bad authors get paid by publishers by the number of pages, and publishers push the books to education, where the attention economy takes care of the rest.

Good thing that programmers are more often self-learned, which makes the problem relatively benign compared to say, economics books.

Too bad authors get paid by publishers by the number of pages

This is not true. Authors get paid by the number of books sold, period. For my book we had an approximate target length, but that was a precondition. Past that gate, all we saw was $x/copy.

I've heard it independently from people working at my economics and finance department. Are you sure it applies to all textbooks?

I've never ordered or written a book myself, so I could very well be wrong.

I worked as editor for O'Reilly and am an author for O'Reilly, and there's no page count juju in our royalty payments. You get paid 10% of what we get for books that sell. End of story (for print, things get weirder in ebooks but not so weird that pages enter into the picture).

The only thing that's important about page count is that there be enough pages that the book's title is visible on shelves and not so many that you need to reinforce those shelves.

This minimum page count, by the way, is why so many business books suck: they have an idea and examples that they could get across in 10-20 pages but have to stretch it to 300 generously-whitespaced repetitive pages in order to have a physical object on shelves to sell. For this reason alone, we should hail Kindle and other ebook platforms that let you make money from 20 pages. If I never again have to read the business equivalent of an ASCII table, I'll be a happy man.

Completely agree!!

Reply on news.ycombinator.com