Point #2 is the Little Coder's problem _Why spoke of: a beginning programmer is likely to be discouraged by the vast difference between the toy programs displayed in introductory books, and the real code that inspired them.
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?
The "worthless example to explain features" in my pet peeve...
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.
As a semi-new programmer myself, I can't agree enough. OOP concepts like classes in Python were initially very foreign to me. The book I learned from gave no real world examples -- "Image the super class is a bird. Now we can subclass a canary! Clearly you can see how powerful classes are in Python!". I skipped the rest of the chapter because it seemed like something I would never need.
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.
Forgive me, but I'm really new to programming, and I don't really understand why your example is something that shouldn't be used in real programming. Should a Car be a Vehicle object instead of a sub-class?
The problem lies in that you never have a "Car" which should inherit "Vehicle". It's a question that never comes up in programming. The bad part of it, is that it sometimes makes new programmers look for these kind of concepts in their code, and write class-based code around them. Exactly the problem http://pyvideo.org/video/880/stop-writing-classes discusses.
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.
I don't think I have ever read a programming book that teaches OO in the same way that most developers use it - that is implement top level first and then when you have commonalities between objects abstract them out into parent objects.
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.
One of the very first things I learned almost immediately after college is that inheritance typically is a bad idea and that composition is a better strategy. With inheritance you have so much thinking overhead with parent to children relationships when most abstractions could easily be viewed as building it through small pieces. Its sad but during my 5 years in UCLA I have not heard the word "composition" once.
The point is that OO isn't everything, and making the first thing people learn being class hierarchies colors their perceptions of programming in ways that sometimes are very damaging.
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.
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.
I started learning programming in January using K & R. It is a wonderful book which avoids all of these problems.
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.
My pet peeve is books that show the wrong way to do something followed by the right way. If I'm new to a language, I haven't committed these sins yet, so please just skip to the preferred method. All this does is add mental overhead.
It seems to be not only programming language books' fault. And not only books' fault. Even teachers at schools and universities sometimes show wrong way of doing something.
3: If there are multiple valid solutions to an exercise, list them. If some solutions are better than others, explain why. If there are solutions which are technically invalid but commonly thought up by new programmers, explain what they did wrong.
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?
#1 is a great point and a great recommend. There is certainly a place for long, ponderous reference book-like tomes, but they are a poor substitute for concise beginner books. Eloquent JavaScript is amazing in that respect.
I think the right approach would be to print the concise beginner book and bind it with 1000 blank pages. That way it won't be too daunting for the learner, but can still perform well in a secondary role as a monitor stand once they're done with it.
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.
I agree ('the internet' thinks this idea is from Pascal: "Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte.")
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")
I believe there is a start-up that is gaining traction that is looking to remedy all of those issues. I can't remember what it's called right now, but the concept is you learn to program online in an environment that shows you where the mistakes are and also what the outcomes are to keep you motivated. Seems like an ideal situation; and frankly it's a little surprising something like this hasn't come out sooner considering most programmers go through this sort of pain... Maybe it's seen as a right of passage, if you can put up with the BS, you deserve to be a programmer?
I'm no expert, but I think it's possible that the fact that's a book at all may be a failing. The goal is to get them writing code and seeing results, as well as mimicking their later real world experience of experimenting to find the right answer. That's why I think things like code academy better reflect the way we'll be teaching this in the future.
I’m not sure I agree. Sure, programming is a craft, and the only way to learn it is to do it. But I see no reason why a book can’t serve as an introduction, giving the reader projects to complete and guidance toward completing them. Being that they lack interactivity and mentorship, sure, books are difficult to make into what beginners need. But just because they’re not the best medium doesn’t mean they should be completely discounted.
Let me begin by saying that I don't think books aren't the right approach for every programmer - simply true beginners.
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.
How about another one.. "Takes too long to get to the interesting parts."
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.
My pet peeve are books/tutorials that spend most of their time in the interpreter. I appreciate interpreters for what they are, but I don't thing the ability to type 2+3 and get 5 is relevant to any programming language skills.
- 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.
I was thinking about how I never "look at the language's documentation" when a book or tutorial tells me to.
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.
This is a huge annoyance for me, as is providing an example in the terms of 'A', 'B', 'C', and 'D'.
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;
....
Another thing is stuff like this:
Array.sort(function(a, b) {
return a - b;
});
Firstly, if you're a beginner, that means absolutely nothing other than an array is being sorted. Secondly, if you do know what it is, it fails to explain what else you might be able to do other than sorting from lowest to highest.
I hate 'foo' and 'bar.' To newcomers they probably conjure up ideas of sin/cos/tan rather than plainly represent placeholder names. 'DoSomething' or 'SomeFunction' or anything like that is prefereble.
I sympathize, but "foo" and "bar" are used when the name is beside the point—i.e., precisely when no thought process should go into naming things. See the entry on "metasyntactic variables" in the Jargon File more more information (http://www.catb.org/~esr/jargon/html/M/metasyntactic-variabl...).
Although point #3 has also annoyed me no end, I believe I learned a lot from being forced to solve problems myself. Peeking at the solution is just too easy and severely diminishes what you can learn by being forced to think more about the problem. I believe Introduction to the Theory of Computation by Sipser gets it right: answers to about half the exercises.
Totally agree, except for his point three - beginners typically don't care about exercises, they want to get something working. As long as it works and does what they want, they're happy.
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?