What I hate about “beginner” programming books
allfuzzy.tumblr.com
allfuzzy.tumblr.com
I think any purported attempt to teach programming which does not end with the student creating a non-trivial, cool app, is a shame. What went wrong between SICP and current (non-Hartl/Shaw) beginning texts?
This is something like "we're going to have a class named Vehicle" and "class Car inherits Vehicle" in an OO language.
You would almost never use something like this in a real program, and it takes what's a minor and problem fraught feature (inheritance) and quickly has new programmers creating bizzaro hierarchies that never should be.
Basicly it teaches people to think in taxonomies, which is not good for object-oriented programming since it usually results in highly complicated code, with way to many classes and inheritance.
Inheritance is mostly good for factoring out common code between different sub-classes. Or extending library classes in a way that wasn't thought of when they were written.
Thinking about and mapping out class hierarchies is something that Java enterprise analysts do.
A good example to teach OO would be a config parser. Write a config parsing object, then sub-class for parsing Yaml, INI, XML, etc.
For example, about 15 years ago I was an idiot and managed to get a job writing some text parsing code. I, of course, used what I just learned in my Comp Sci 101 "Intro to Programming" class and did a fully OO implementation in C++ with iostreams that took nearly a month to write, and never quite worked.
Looking back, the solution was probably implementable in under 10 lines of a scripting language with judicious use of regex.
The point is that people often fall for the first thing they're given, and OO (which incredibly useful when used properly) is an extremely enticing concept that can be very distracting from actually getting a job done.
I would also like to gripe a bit about boring examples. One of the books I chose while starting out was Beginning Python.. My lord, what a travesty! "Think of a dictionary as a fridge." and "Now for this exercise, we're going to make an omelet!" my eyes would glaze over from boredom. It made it really fucking tough to be excited about the learning process when the assignment is making a digital egg.
I disagree on his book length point, as well. If done correctly (which I have found to be all to rare unfortunately) having a giant book filled with thorough explanations is a great value, in my opinion. By far, the best programming book I have ever read is Programming in C. It's pretty damn massive. Somewhere in the area of 600 pages at least. But I loved every bit of it! All of the end of chapter exercises were like little puzzles that needed to be solved using the newly acquired techniques. They were actually fun to do! and gave a great feeling of accomplishment once I finally figured out how to do them.
Way better than making some crappy pretend omelet!
One final gripe for you future book writers. I would love to see mid chapter exercises rather than one big end-of-chapter dump. Each new concept should be given time to be internalized -- or at least familiarized -- before moving onto the next thing.
Those arbitrary and excessively long introductory chapters that teach you the history of the language. Granted, that might have some merit in a classroom setting where an instructor is going to ask you a pointless question about who designed the first interpreter, but this is the sort of thing that should be kept to a minimum, or kept out.
Zed Shaw's "Learn to code the hard way" are brilliant for this. They get right to it, nothing you don't need to learn and get your hands dirty.
It's short. You write challenging programs in the tutorial introduction. And the accompanying "C answer book" has good solutions for all the exercises.
I also like the fact that each example is a working program. You learn the concepts by applying them. And the exercises really make you think.
People say its "not for beginners". I actually think it's an ideal way to start. The "beginner" books are just confusing.
I would also add a forth point: "Overdoing the 'lol im not like those nerdy others programmers, im a regular normal person like you' rhetoric. Instead of mentioning an old cliche (and then trying to distance themselves from it), why not just not mention it at all?
More seriously, I think that the discipline of making a shorter book usually produces better writing. If you're going to write something longer than say 300 pages (about 1 K&R-length) you'd better have a lot of interesting things to say.
Problem is that that short book, having taken more effort to write, would have to be more expensive (paper, printing, distribution, etc. cost 'nothing' for any book worth anything at all). Selling a shorter book for more money is possible, but customers typically prefer the longer book ("more is better, and even if it is not, I just don't read the extra stuff")
In my experience beginner programmers get stuck very quickly on very small and frustrating bugs, such as not understanding how to put together the syntax. If they can't overcome this quickly, you may completely lose them. This is where the book completely fails as it can provide no further assistance. Even if the answer is provided in the printed text, the individual may not "see" the difference between what they've typed and what the book has printed (it may take a while to get used to the computer-level of exactness you need when comparing code, and to overcome some punctuation blindness they may have developed from normal reading, etc.).
Similarly, I believe it is bad to read too much before doing anything, because as you read you believe you are following along: "uh huh, that makes sense, sure, got it...", then a whole chapter in you may actually start coding and notice you don't really know what's going on (or again, simply think you don't due to some simple syntax mistake). Now the individual will feel overwhelmed as they have an entire chapter's worth of material that they may or may not understand. Even if there are exercises in the middle, people often say "oh thats easy and makes sense" and skip it since its a "waste of time" (which is bad, because its very easy to think you understand something when they don't).
Having seen a few people use codeacademy, I now believe that it may need to be taken a step further: I think for the first few exercises the code should actually be ghosted so that the user is literally "tracing" over it (as opposed to the current technique of saying "now type this in the console"). For example, as I described in a previous comment, one person got completely stuck because it said "Now type variable.length.". The user didn't notice that the last period wasn't part of the code and unfortunately the error isn't very beginner-friendly: "Expected an identifier but found '}' instead" -- "what, I didn't type a }? And what's an identifier?". I believe ghosting the text and beeping when you type a character that doesn't match can give you a feel for the code -- its kind of how rewriting notes really helps it sink in vs. just reading them. Then, slowly take the training wheels off.
i.e. learning Obj-C and taking until the very last chapter to give even a cursory intro to apps. By the time they get there a ton of people will be burnt out / disinterested.
- Please stop including math in every example. I just can't stand see another fibonacci example. Ok we get it, it's awesome for showing recursion, but use other things. Also, don't put math problem on exercises. I'm learning a language, I don't want to recap all my scholl math at the same time. I'll die if I see another "get all the prime numbers from 1 to 100" yada yada yada...
- Don't use the concept of "throughout the chapters we will be building an app...", most of the times these apps suck and are plain boring, and it's demotivating for the beginner. Instead create different small apps in every chapter.
- Bonus: It would be awesome if books started including a cheat sheet.
As a beginner/intermediate coder myself, I can't just "look at online documentation" because I don't truly understand how to use it and understand properly. Does anyone have a good resource for learning how to use documentation?
I know that may sound trivial to experienced hackers, and possibly paradoxical, but I'm actually quite sincere about this request.
PHP's manual is terrible for this. It's not just a naming problem, but a total failure to explain the purpose of that concept or function with a proper use-case.
class A {
public function a($a) {
$this->a = $a;
}
}
class _A extends A {
}
class B {
public function b($b) {
$this->b = $b;
}
}
$foo = new A;
$bar = new _A;
$baz = new B;
....
Array.sort(function(a, b) {
return a - b;
});