With two exceptions – I’ve reviewed PHP Programming Solutions and shall review Cocoa Design Patterns later – the books I’ve seen on Cocoa/Objective C (and a number of other languages/topics) follow the same pattern.
That’s it. The Intro can – if Objective C is covered in detail – be quite long. The taster used to be Hello World; these days most introductory Cocoa text skip the command line output and let you build a real, live, mini-application, just so you can et a taste for Interface Builder and how easy it is to hook things up.
After that, the pattern tends to be that you are taken through projects in increasing difficulty – sometimes a single application, sometimes several.
I’m not disputing that this can be enormously helpful. Anyone who sees the ease with which Cocoa allows you to build a fully-functioning Mac application with very little effort will be hooked – should be hooked, and it is wonderful to work through a more complex project and see what -it – and you – can do.
The problem is, this is a lousy way to _learn_. For the most part, the reader will be passively consuming code and writing-about-code, he will retype (if he’s lucky and the instructions are correct and well formulated) or simply look at the sample app (if he’s lucky and there is one and it runs on his system).
How are you supposed to make the step from reading to understand what is going on? Magic. Or rather, mimesis. And much as I try to imagine what kind of brain you need in order to not just be able to learn programming from this, but to _find it an efficent way of learning_, it is beyond me. It is not, in the strictest sense of the word, _learning_ – because learning implies understanding; and understanding requires abstraction: not just how to do something, but why, and how to construct it when you have forgotten the details.
When faced with large blocks of text and code, I find that very little learning occurs. I do not _understand_ these things, and because the pace of these books is ever-increasing, I understand less and less as the book goes on. And even when I can follow along what is happening (which is not the same as _understanding_), I find myself absolutely utterly incapable of taking the things I’ve learnt and applying them to my own applications, because they are so bound up in the original project that it is hard to separate them out.
This leaves me, at the end of the tutorial, with the ability to mimic the sample applications – and I usually need the book to do it, because they’re pretty complex things.
As society, we don’t expect people to learn anything else in this manner. We break down information and present it in different ways, accommodating different learning styles, and we develop practice activities to confirm knowledge and testing to see whether the learner has understood it. If this discussion exists in computer science, I don’t see it, and it certainly does not appear to trickle down to people-who-write-tutorials. Consequently, most questions I see are ‘I tried to use x to do y, but it doesn’t work, what should I do?’ with answers ranging from ‘read the manual’ to ‘use z instead’ – what I don’t see are higher level discussion: how does one cope with the flood of information, how do you develop an application, what are good strategies for setting up things and testing them.
People obviously learn to program somehow – the trial-and-error method will lead to applications (though not necessary to best programming practice) – but it’s not efficient, and I wonder how many people start out and give up because they don’t feel they’re learning anything useful. Couple something as inefficient as most computer books with a culture that tells learners ‘it’s insanely difficult’ and you have a powerful mechanism for discouraging learners.