This is not your average Python book -- it is a college text intended for first-semester CS courses that happens to use Python. As such, in assumes absolutely no previous programming experience, and it looks like any previous computer experience is optional. Not only that, but the book starts with a step-by-step introduction to the art of computational problem solving. This is an idea that goes well beyond hacking together a website!

The book is incredibly thorough: there are exercises throughout the text (not just at the end of each chapter), and it includes a plethora of examples, screenshots, tables, charts, diagrams, and photos. (Yes, my picture is in there -- so are Alan Turing, JFK, and K&R. :-)

The author is not afraid of taking a stance; for example, he omits the 'break' and 'continue' statement because they do not fit within the paradigm of structured programming. This actually fits with the general goal of the book, which is to give an overview of many areas of computer science without getting too deep into the minutiae of any topic. I love the final chapter, which is an overview of the history of computing, starting with Charles Babbage and Ada Lovelace.

At the same time, the book gives plenty of useful practical information, such as instructions for using IDLE and an extensive explanation of turtle graphics, culminating in a horse race simulation. (The author's Baltimore roots seem to show through here. :-)

All in all, I think this book is a great text for anyone teaching CS1 or interested in familiarizing themselves with computer science through serious self-study.

7 comments:

Teaching CS1 without break statement?? We, as a civilization, value taking the stance precisely because it makes it easier to see if somebody is right or wrong. And he is, simply, wrong here.

I've seen people like him. They (if they are consistent) also believe every function should have only one return statement, and it has to be at the end, outside any loops. Exceptions are banned -- because, hey, what is essentially a break, or return from a loop, than a well-packaged exception?

They are much more likely to litter the code with various boolean flags, setting and clearing them as needed, and add them as additional constraints at the beginning of the loop, having to duplicate code between loop start and break point after the loop.

Moreover, Python makes it exceptionally (no pun intended, unfortunately:) hard to do so; and Python is right, because there should preferably be only one obvious way to do it, and it _has_ a break statement. Instead of simple for loop over any iterable, you have to use while loop if you must add a condition, and then it becomes the nightmare of indices, inequalities, off by one errors and various other wooly stuff that makes people think programming is hard.

continue is mostly a syntactic sugar (but in language such as Python, where every condition inside nested loops shifts left margin one more level to the right, it's really nice to have it), but break is essential to structured programming.

I suppose he doesn't by any chance have a picture of Don Knuth in his book? Because if he has, I'm telling him to Knuth right away. :-P Knuth was writing about this phenomenon, almost 40 years ago. See http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf. His verdict: even goto is correct in some cases (this was before exceptions became easy to use). And removing features of well designed languages in name of some philosophical point never ends well, and usually accomplishes the opposite.

As an actual student using this book, I can tell you it is riddled with mistakes. This book is to provide the student with a foundation and an introduction to programming but when there are blatant grammatical errors (which spell check could have easily caught) and periods, underscores and other elements missing in the book, it makes it extremely frustrating to learn. If anyone can give me some guidance on who to contacting to get these corrections implemented, it would be truly appreciated. Hopefully I can save other people from having an extremely frustrating experience.

Guido.Please, add the "begin/end" commands for define blocks in Python.For a language you want to define as easy to understand, the lack of these commands is not clear to developers that they feel much better documented with beginnings and blocks purposes. It is a very small price to pay in two lines and not have to worry about all the other to remain within the scope of action for any Block when necessary. Indentation was a very well thought-out solution and so was placed in languages that originally had not (but still not having). Believe dozens of languages breeders who use indentation can not be wrong when compared to a single developer that wanted to do different. Think about it.