Slashdot Mirror
Think Python
An anonymous reader writes "In a neverending effort to spread the word about free quality online programming books, here is a Python programming book. 'How to Think Like a Computer Scientist: Learning With Python', by Allen B. Downey, Chris Meyers, and Jeffrey Elkner is a copylefted work available in multiple formats at Green Tea Press: HTML , PDF, LaTeX. Compliments of the online books what's new page."
This books has been translated to other programming languages (like C++ and Java)... so if Python is not for (it should be) you can read those too.
Thanks to Copylefted Online Books, I now can read the books before I buy.
On my bookshelf, seven of the books were bought after I read their online version.
I live in a third world country where there is no Towers bookstore, nor Borders, nor Barnes - there is NO WAY for you to know how good a book is without first buying the book - the bookstore here do NOT allow you to read the book !
The idea of Copylefted books really help me, and many others who are in the situation of buying books not knowing if the books are good or not.
Thanks again !
Muchas Gracias, Señor Edward Snowden !
Am I the only person who thought the title of the book was "How to Think Like a Computer Scientist: Learning With Monty Python"?
Man, it's early.
I think part of the problem is the name `Computer Science', which gives a wrong impression of what the core of the poodle really is. That's like calling Astronomy `Telescope Science'. I have met so many people who didn't want to study CS at all - they just wanted to learn `installing Linux and setting up a web server'. This has regrettably put universities under pressure to change their curriculum...
Some universities (eg. Edinburgh) have started calling it `Informatics', which is much more appropriate. (In fact in Germany, and probably elsewhere, it was always called `Informatik'.)
Maybe there should be CS *and* Informatics.
Uhm, guess that was offtopic.
Another excellent free book for Python is Dive Into Python by Mark Pilgrim. It is available in HTML, PDF, Word 97, Windows Help, plain text, and XML formats.
This book has plenty of examples and pointers to further reading on each subject. It features good layout, use of colors, and typography which makes for easy reading and comprehension.
http://www.ibiblio.org/obp/thinkCS.php
I was actually quite surprised to find this article on slashdot. You see, I'm the author of the Perl script which converts the LaTeX source to HTML. I hope nobody finds any blatant problems with the online book websites...
This book doesn't strike me as a book on how to think like a Computer Scientist, except insofar as Computer Scientists generally make lousy Software Engineers. There are no descriptions of the advantages of object oriented programming, discussions of theoretical topics, and in general very little encouragement to view programming as a science. Basically, this appears to be just a book on the Python language, written for someone who has never programmed before. That's a fine thing, don't get me wrong. My brief look even makes me think it could be an effective example of such a book. At the very least, I think it's hyped wrong.
However, from a software engineering point of view, I find it damning that the book forgoes any explanation of the practice of, or motivation for, writing maintainable code. I consider that unforgivable in a beginning programming book. You absolutely have to impress on newbies early the importance of documentation, sensible structure, logical variable naming, good class hierarchy, etc.
I consider this especially true for Python, which is an interpreted non-declarative language (making maintainabilty all that more important). Python is, conversely, also especially well designed as a platform where such concepts could be taught. It largely overcomes the occasional weaknesses of its design philosophy by consciously including language features such as built in support for docstrings, well crafted namespaces, modules as first-class citizens, etc.
Yet, these language features are barely given a nod in this book.
It's books for existing programmers that can afford to skimp on these areas.
Does anyone know if the author of the book gets paid by Green Tea for donating or "copylefting" the book?
I'm working on the theory of collecting tax deductions for copylefted art, and this contribution is a great example because it closely resembles historically donated items. If the author donates the artwork to the right organization - he could by my reading of the IRS be paid in tax deductions.
Does anyone know of cases in Open Source / Copyleft where tax deduction are being used to help cover expenses?
I'm sure that the competition - i.e. Microsoft uses every tax deduction in the book. Are Open Source contributers playing by the same rules - or are we handicapping ourselves by ignoring the tax benefits of donation?
If anyone can provide examples of copylefted donations and how you documented it for tax purposes - I'm interested.
I believe there are Billions of dollars in potential government funding just waiting to be collected by Open Source artists. Lets go get it!
AIK
While Python is my favourite language, I think it's rather silly to teach Computer Science and especially basic algorithmics with a language that doesn't have pointers.
At low level, pointers are everything, and low level is what you want to teach when you're teaching basic data structures and algorithms. There's simply no point in demonstrating list implementation with an interpreted language that has very efficient native lists, dictionaries, etc. C/C++ or Pascal are much better for that; with them you can teach real implementations, not toy ones.
On the other hand, Python might be ideal for teaching advanced algorithms such as sorting and string algorithms, as those are more "high-level" problems and low-level pointer-messing is no longer needed nor desired. Python has very beautiful string and list operations, which make such algorithm implementations cleaner.
Also, Python might be ok for the very first Basics of Programming course with respect to pointers, as they don't really teach any algorithmics there. However, the weak typing (very late binding) would be a problem in this case. Beginners will have enough trouble understanding the language without the need to handle implicit types. I'd very much suggest a strongly typed object-oriented language such as C++, Java, or Eiffel, where the types are always explicit. For an algorithms course this isn't so much a problem.
For some classes, such as AI, there's simply no winner for Prolog, and perhaps Lisp, but many Python features such as easy string manipulation and other middle-level data structures make it temptating for many subjects such as Automata and Formal Languages. It would be interesting to have a good Python interface to a Prolog interpreter; one that is well integrated with the syntactic philosophy of Python.
Hmm... to be honest... the "Feynman Lectures on Computation" are just about as absurd as the "Goedel Lectures on Biochemistry" (these don't really exist... I'm just being sarcastic). The original poster's comments on Feynman had some merit.
The phrase that you quote here displays a mind-boggling ignorance about exactly what "Computer Science" is. Software Engineering is, indeed, "like Engineering" but there are many branches of Computer Science that deal *purely* with the abstract. I do Formal Language Theory and Automata Theory for a living and I just can't see how these fields are about "getting something to do something". Feynman, like most people, has missed the science for the telescope.
The real joke is that things like the Church-Turing thesis could not possibly be MORE about "natural objects". In the abstract, I can define a machine that can solve the halting problem. Heck, I can define a machine that solves any problem I want! The Church-Turing thesis tells us about a PHYSICAL limitation on computing. In this universe, you can only build a machine that will compute *these* functions.... But what if I live in a universe where time has no meaning? All of a sudden, I get a *very* different Church-Turing thesis.
There is no question that Feynman had some brilliant insights in physics, but I have to admit that when I read the Lectures on Computation, not only did I lose a small amount of respect for him... I found myself actually outraged. Many intelligent people will read these lectures and believe them... I mean, after all, they're written by Feynman, right?
Computer Scientist's have enough trouble trying to explain to people that, no, we don't just sit around installing Windows network drivers all day without a respected and intelligent person like Feynman adding to the problem.
I've written a review of this book on The Assayer. The book is self-published (the authors run Green Tea Press), and one of the things people don't realize about self-publishing is how hard it is to attract reviews. (Actually, it's hard in ordinary publishing, and even harder in self-publishing.) Without reviews, you don't get much credibility. So if there's a free book in The Assayer's database that you've read, please write a review!
Find free books.
"How to think like a computer scientist" is a bit much for this book. It's an introduction to Python programming, and at best, a mediocre one. It's aimed at the overpopulated "first book on programming" market. The book reads like a BASIC programming manual of 25 years ago.
You have failed to understand the point of Computer Science (pun intended). Python is a terrific language for teaching CS because it has the basics of discrete structures: lists, maps (in Python, called dictionaries), tuples, and atomic data types such as strings, ints, and reals. That's all you need.
There's really nothing you can't do once you have lists and maps. Don't object that you can't have O(1) access-time arrays -- you can do that with a map.
I challenge you to describe any algorithm at all that can't be implemented without pointers. If you think you need pointers, you just aren't thinking like a computer scientist.
For some classes, such as AI, there's simply no winner for Prolog, and perhaps Lisp
In general, you are absolutely correct. Of course, this is opinionated and others may disagree. But remember, you can use any Turing-complete language to simulate any other Turing-complete language (that's the entire definition of Turing-complete). Which means I can write a C interpretter in Prolog if I want (and I'm feeling particularly masochistic), and therefore I can simulate pointers using Prolog.
Oh, but you cry "That can't possibly be efficient!" Right again. But you've again missed the point of Computer Science. CS is about efficient algorithms, not efficient programs. That's something we leave to the software engineers and other "implementors." Us CS freaks think about what can be done, we don't actually do it ;-)
No doubt, Feynman was a very, very good physicist. But he was also a genius at self-promotion, and his cult has gone way overboard as a result. It's well-established by now that some of the ideas he's famous for were first published by others.
(Not that he wasn't honest about it sometimes. I think he's on record, for instance, crediting Stueckelberg for the renormalizion of electrodynamics, and for the idea that positons are electrons travelling backwards in time. See e.g. this timeline, or the last chapter of this book.)
Timeo idiotikOS et dona ferentes
That said, I don't know if I would teach a begining computer science course in python. At my University, our general intro to CSE involves a two class series teaching generic basic theory wrapped around a programming language. We used to teach them with C and C++ but just recently moved to Java. I have been a TA for these classes before. Based on my experiences, I think there are both pluses and minuses to the idea of teaching these classes in python.
Benefits:
- Python is extremely easy to learn, as mentioned before. Much easier than C, C++, or Java.
- Python works really well with Tk, which would make it easy to build out skeleton code (multiplatform skel code at that) for the students using windowing and graphics. Students are 100% happier if they can see what they're working on reflected graphically. Makes it more fun to show off. This is why our projects usually include basic games.
- BASIC Python is truly, completely, multiplatform, working identically on Mac, Win*, and *nix. Some specialized functions in modules don't support all platforms, but nothing that would be important to a begining student. Support issues would be MUCH simpler than C or C++. God, we had huge headaches trying to support MSVC, CodeWarrior, CodeWright, Borland, etc. . .
- There is a great installer script available that will build python modules into either standalone exe's or distributable directories. (Available here if you've never seen this before)
But, there are also some downsides that would have to be weighed. These are:Looking away from basic intro classes, python is great to know. I did a lot of AI code sketches in python, and have used it to slap together simple programs at work. However, I would consider it a tool to be learned after the basics have been beat in. If I had learned python first, it would be a lot harder to force me to do everything in C later.
-s
- - - - - - - -
Don't worry, being eaten by a crocodile is just like going to sleep in a giant blender.
However, for the last hundred years or so it has really been increasingly difficult to separate science and engineering. More and more, scientific hypotheses can only be tested when sufficiently advanced engineering comes along. There have always been "whiteboard scientists" (i.e. theoreticians) who resent this.
But most great scientists were skilled engineers as well. Galileo, Newton, Bunsen, Babbage, Turing...
I think the terminology is the problem. We don't talk about "Physics science" or "Biology science", so why "computer science" or "rocket science"?
Why not just computing and rocketry?
While I'm having a rant, there's also a problem with degrading the word "engineer". MCSEs and such are basically technicians, not engineers. Perhaps if we admitted that the people who implement systems using standard components that just have to be set up correctly (although this may be a challenging role) are technicians, then we could accept that most "computer scientists" are actually trained as engineers, that this is a highly skilled and challenging professional role, and the number of real scientific researchers is not that great. Just like physics and chemistry nowadays, in fact.
I would suggest that the test of a pseudoscience is that it doesn't create a heirarchy of engineers and technicians because, basically, it doesn't work and there would be nothing for them to do. You don't get sociological engineers designing ever better societies, and socio-technicians building them just as fast as people can throw money at them. (At least, the attempts, such as Marxist-Leninism, have been abject failures). But you get plenty of sociologists. On this basis, computing, with its deep organisational structures, is an extremely successful science-based system. Arguments about testing hypotheses are irrelevant: real scientists tend not to work like that anyway.
Scientific proof has been conventionally about other people reproducing your results. But if the nature of your science/engineering is that you can rapidly produce millions of copies of your concept or invention, this becomes trivial. If I claim to have invented (say) a graphics chip architecture that can draw polygons twice as fast as the previous best for a given clock speed and die size, I prove this by marketing the product, not by publishing and waiting for other labs to build a copy and duplicate my result.
Panurge has posted for the last time. Thanks for the positive moderations.
If you actually look at the book in question, you'll see that the original poster was correct: it's not about computer science at all. It's a Python programming book with a marketing angle relating it to computer science.
If you really want a book which teaches "How to Think Like a Computer Scientist", try SICP. For a good summary of the book, see this comment from the recent "Best Computer Books" article.
At low level, pointers are everything, and low level is what you want to teach when you're teaching basic data structures and algorithms.
Conceptually and from a computer science perspective, the object references present in languages like Python, Java etc. are equivalent to pointers in all the ways that matter for representation of data structures and algorithms. In the academic community and elsewhere, it's generally considered beneficial to teach such things without reference to the machine pointers which you're referring to, since machine pointers carry a lot of baggage that's unrelated to the abstractions involved in data structures and algorithms.
There's simply no point in demonstrating list implementation with an interpreted language that has very efficient native lists, dictionaries, etc.
To refute this, let me offer a tutorial: A Gentle Introduction to ML. If you work through this tutorial, you'll very soon begin implementing functions in the ML language for basic list operations and the like - functions that already exist in the language. And guess what: the implementations that the beginner typically comes up with in that tutorial are very close to the actual implementations that ML uses - the tutorial gives some examples of actual implementations for comparison.
This high-level operation doesn't even cost much -languages in the ML family, including OCaml, regularly are top performers - see e.g. Doug Bagley's language shootout. They can perform on par with languages like C because their type systems allow sophisticated compile-time optimizations to be performed, and their high-level abstraction features are supported by optimizations such as tail recursion.
C/C++ or Pascal are much better for that; with them you can teach real implementations, not toy ones.
If you believe that C/C++ and Pascal are good languages for teaching computer science, you don't know much about modern computer science. All three of those languages have very weak type systems and lack basic features that allow the construction of high-level abstractions.
Pascal is all but a dead language in the CS community nowadays. The primary use for C is as a decent portable assembler. Learning C has very little to do with computer science, and absolutely nothing to do with teaching computer science concepts.
The C++ spec certainly specifies that the return type of main() is int. It's covered in 3.6.1 of the C++ standard. (I'm pretty sure the same is true for C).
Also, in practice, different implementations require different return types.
They're not conforming implementations if they require that main() doesn't return int.
I think part of the problem is the name `Computer Science', which gives a wrong impression of what the core of the poodle really is.
Well, yeah.
I'd make the following analogies:
CS is a science that deals with unravelling how information and logical systems function and developing frameworks to understand them. CS are most likely to determine the boundaries at which things can happen and to lay out how to practically approach that boundary.
Software Engineering is an engineering discipline that deals with manipulating those systems to perform a needed task. They take the work of the CS and design systems to address specific problems. Quick and dirty is just fine, provided that all the needs are being met.
Coders assemble the systems that the SEs design and informaticians maintain those systems.
There's overlap among all of them to some degree, and plenty of people do them all, but from an education point of view, if you mix them together, you get a mess - and most schools mix them together. It was easier to mix them in the past because the field was narrow. But now, you just can't do it.
CS has become very deep, and you can't get into any of the real work if you spend your time dealing with SE and coding practices. SE has become very deep as well and you don't want these folks getting bogged down with the NP completeness proofs and whatnot, or with learning the programming tools too much. There's enough to do in all three areas that they need to be treated as different but complementary disciplines...