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.
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.
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.
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 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.
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.
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.
'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.
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.
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."
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.
