Mr. Shaw, i am once again impressed. This is not the first time I've seen Zed Shaw rant about something he dislikes and then goes off and attempts to fix it.
So far, the exercises do look like their targeted to the total beginner, but my money is that most programmers learn Python as their nth language, where n > 2. I say "so far" in hopes that he eventually gets enough exercises in the book that the material included now is just a small part of the finished work.
Doh! VB index alert: The exercises are 0-based and the steps are 1-based. ;-)
"but my money is that most programmers learn Python as their nth language, where n > 2."
Off the top of my head, I know at least 3 Universities (near me in Canada: UBC, SFU, UofC) that have recently switched to Python as the first language taught/used in their CS programs.
There is a real demand for intro Python books. And IMHO Python is a pretty good first language.
I think the Head First series is actually quite good for teaching Python as a first language.
I recently purchased the Python one (it's just called Head First Programming from memory) for a friend who wanted to start with coding and she picked the basic concepts up pretty quickly.
SFU still requires their students to learn Java. Python is the introductory programming language of choice, and the introductory programming course is centered around it, but it isn't a requirement. (reference: http://www.cs.sfu.ca/undergrad/Advising/programs/majors.html ; I'm also close to the associate dean).
That being said, Python is a wonderful language to get started in programming.
My thinking is actually this: Python is a weird language that sits between C and Smalltalk It has odd idioms from C and strange constructs from Smalltalk which you don't really find in other languages. It's also very easy to type with a lot less "signpost junk" in it. My idea (totally unfounded) is that will make it easier for people to type it in, and also teach them the little secret idioms found in languages on both ends of the spectrum.
Also, there will be a few jokes about cardinal vs. ordinal numbers.
Except for some dabling in basic, max/msp and some proprietary scripting stuff, Python was the first language I learned. It was certainly the first one I learned to program in.
Coming to Python with previous programming experience, I was impressed by the Google Python Class. It feels like it crammed my usual first few weeks/months of "oh you can do it like that" moments into a couple of hours. Which makes sense as I believe it's what they give to new hires there who don't already know Python.
FWIW I didn't watch the videos, I just read over the webpages.
Anecdote of one, my 12 yo son is learning Python as his first programming language. I just helped him through one of his math homework questions in Python; found a homework error. :)
A few weeks ago, I finally gave in and tried to learn Python. It is surprisingly easier to learn. From a guy with mostly C and Perl experience, it takes good parts from both. I was writing code in only a few days. It's also easier with StackOverflow and Google, of course!
"If a programmer tells you to use vim or emacs tell them no. These editors are for when you are a better programmer. All you need right now is an editor that lets you put text into a file."
Ha! When I started to program, everyone told me the opposite. After weeks of head scratching and spending more time learning editors than coding, I secretly switched to Pico. But man could I use the hell out of Pico.
This is exactly why I have such a soft spot in my heart for TextMate. I used it like Notepad until I knew what I was doing, and although I'm far from an expert I'm still pulling new tricks out of it.
I'm sure there are other, similar options but TextMate has been good to me.
I'm actually looking for a simple editor that works on all platforms, doesn't look totally like ass, and is easy to use. I'll then change things up so people just install that. Basically a GUI cross platform pico would be perfect.
I second gedit, just installed it on my Mac, and it doesn't look like complete ass. (It does however use GTK for file open dialogs etc. so that might put other people off?)
Hasn't Apple somehow killed GTK on Snow Leopard? There was something that made gvim stop working, so I had to switch to mvim. Sorry can't remember the details, but gedit might be hurt, too? Or was that just a MacPorts problem?
There's TextMate on Mac, and e-texteditor for Windows (which is a port of TextMate)... but that leaves Linux high and dry until the developers finish porting it there too. It requires cygwin under Windows too :/.
Other than that, there's SciTE, which is quite nice. Notepad++ on Windows is a derivative thereof.
Nedit http://www.nedit.org/ might be too much like ass for you, but it's pretty simple in the default state and isn't just a GUI wrapper around a character-terminal editor.
The basic vim commands are easy. As with python you can ignore the more advanced topics until you are ready to take advantage of them. It has a GUI interface so users used to pointing and clicking will feel comfortable.
I agree, vim is overwhelming at first. It simply does not work like a new user expects... i.e., you can just start typing and using arrow keys.
Nano is much more straightforward.
What these people should really be using, though, is Kate on Linux, or Notepad++ in Windows. I gather that Textmate is the equivalent for Macs, but I've never used that personally.
Syntax highlighting and a multiple document interface goes a long way.
I suggest reading the nascent PDF that he's posted, it's very good in some ways, less good in others, but if Zed keeps it up and is willing to have others help shape his voice, then this could end up as a very valuable project.
The items on my "less good" list are admittedly subjective, but might be worth considering as you continue to develop the text. And in this case, I mean "less good" as "not bad, but not yet great."
For instance, should you be using printf style formatting when string.format is is available by default in 2.6, Snow Leopard's default python?
A weaker argument could be made for importing print_function from __future__, but I don't believe the added complexity is worth it, even if it eliminates a special case.
In Exercise 0, you might want to stipulate a python version, since some intrepid readers will search out the "latest and greatest" python, and they will download 3.x unless explicitly told otherwise.
Beyond that, I think some of your prose could be improved. For instance, "Notice I use a text editor called vim. You shouldn’t use it, it’s too hard to use for you right now." may be a bit off-putting to someone completely new.
The statement after your listing, however, is perfect:
"If a programmer tells you to use vim or emacs tell them no. These editors are for when you are a better programmer. All you need right now is an editor that lets you put text into a file."
I think you should bite the bullet and recommend a few text editors on Windows, Mac and Linux. Or one cross platform one. Some poor bastard is going to end up wondering why test.py.doc isn't running - and I don't think it's fair to cast them off as too stupid to program for that.
I am relatively new to Python and wrote a Django app using string.format through and through. Then, I had to install it on our server... which apparently uses Python 2.4 and we can't upgrade at the moment. It all had to be changed to the printf style to be compatible... so, I think learning that is still relevant since it works in every Python version.
From the book: "You might not really learn
“programming” from this book, but you will learn the foundation skills you need to start learning the language. "
This is good. There is a place for books like these.
If nothing else, he is at least following-up his "DiveIntoPython is crap" words with concrete action.
It would be really interesting to sit someone down who is fairly comfortable surfing the web, answering emails, using iphoto or microsoft word, but who has never had any experience programming before, and see where they trip up and where they are bored in working through this.
I know a few people I might be able to talk into it. If I do, I'll report back.
If you do, take notes, and let me know every part they have a problem with. Usually there's some "magic word" or missing bit they didn't know, or that exercise is just total crap.
My brother agreed to try it once school is out in a couple weeks. I think he's a pretty good candidate: computer savvy and uses a mac, is interested in what I do but has never tried to learn it before. I'll definitely take notes and pass them along.
Funny, you read that as saying, "Zed's wrong." I read it as, I may be right. For example:
> no one challenges KSC on the basic premise, that putting introductory students in the position of discovering information for themselves is a bad idea!
The article doesn't say, "Don't get programmers studying code right away." It also doesn't say they shouldn't work on problems.
It says that the constructivist approach to teaching by giving students very little direction on complex problems right way isn't effective. Instead the direct instruction method of having them work on directed problems to build initial capabilities is more effective.
This has been the position of the direct instruction school of education for a while now. In fact, if you actually RTFA they mention that the constructivist model of is the failing. If you then read the linked articles you'll find the same thing.
Not a single thing in that linked article supports what you've stated.
Not a single thing in that linked article supports what you've stated.
I stated: "the concept of getting people programming ASAP in order to learn has been sort of poo-pooed". This is based on the article stating that programming "is a bad way to start" and "expecting students to program as a way of learning programming is an ineffective way to teach."
Funny, you read that as saying, "Zed's wrong."
Why would I have? That would be a meaningless and uninformed judgement. The effectiveness of the techniques is the interesting part. My observation - accurate or not - that the article "poo-poos" a technique is not to say that the technique is "wrong" as linking to an article says little of my opinion, which I stated as being "on the fence."
Wow, thanks for posting that link. I’m really glad the ‘learning by doing’ methodology is under some scrutiny, because it’s not the way I learn at all. For what it’s worth, if I had come across the draft of Zed’s book when I was first learning to program, I suspect I would have hated it, very quickly gotten bored, and dropped it in favor of something else. I can’t stand being presented with the absolute minimal amount of explanation required for something. Glossing over the details is the quickest way to lose my interest. I need a complete, in-depth explanation, even if I don’t necessarily understand it all at first; I will come back later and re-read parts because I know exactly where the explanation was.
Another thing that I think would have especially bothered me about this book is that there are exercise upon exercise without answers. I remember being in algebra class in high school and hating that the book didn’t provide an answer to every single exercise; without an answer, doing the exercises was almost completely useless to me because I had no idea whether I had solved them correctly.
Hacking away at something until it works with minimal explanation is certainly one way to learn, but when I’m first learning something, as a novice, that particular methodology just makes me frustrated and angry. I could go into my garage and fiddle with my car’s engine for weeks on end trying to figure out how things work, but that seems like a largely inefficient way to go about learning. There are people who know how a car engine works that can communicate their knowledge to me—after all, isn’t that the whole point of instruction and education: somebody has already figured it out, and they can explain it to you quicker than it takes for you to figure it out yourself.
This isn’t to say I can’t now hack away at something in the dark and probe it to figure out how it works—I suspect that’s a necessary skill for being a good programmer. But learning how to program initially through such a method would not have been ideal for me.
That being said, I think there’s still a lot to be said about the straightforward, practical programming advice Zed throws out. In particular his explanation about the importance of noticing minor differences is really awesome. Obviously people have different personal learning styles, and I suspect this book is geared to those who learn like Zed, so I don’t doubt it would be valuable to those people. I definitely don’t learn like this, though, and I just wanted to point that out.
You already think like a programmer, probably you were either born or raised that way. For example, you already have an attention to detail which is why you demand solid details about every possible thing before you feel as if you understand it.
I actually learn some things like you, but I had to learn to not learn this way when I started studying music. There's actually a lot of things you just cannot learn by first having all the details. Insisting that everything be presented this way will prevent you from learning a vast array of topics that require an intuitive artistic sense or require non-verbal expression.
I would say that if you read this book as a beginner and found it boring then you should move on to the books I'll mention as the next books to read. I would also say that you should try a few other ways to learn something. It'd do you some good to learn something without having to completely explain it first.
skimming thru it now, pretty amusing in parts ... from the beginning of chapter 5:
Every programming language has some kind of way of doing numbers and math. Don’t worry, programmers lie
frequently about being math geniuses when they really aren’t. If they were math geniuses, they would be doing math not writing ads and social network games to steal people’s money.
jokes aside, this could serve as a good syllabus for giving classroom Python tutorials for absolute beginners
I'd like to hear his opinion on "How to Think Like a Computer Scientist", which (approximately) matches his description of a beginner's book, and uses python for the examples.
FWIW, the background is that it has been under a Creative Commons license since 2004, it has had about half a million downloads/readers (guesstimate, of course), is used as a text book for introductory programming courses in at least 8 universities worldwide, and has been translated to at least 5-6 languages by volunteers.
Interesting, it does look like a decent book. Also, it looks like you've targeted Python 3. Seems well written so far based on what I've read in a few chapters.
I'm building a list of free books for people to move onto after they finish mine. I'll put yours in the list.
I love this style. Notably: "if X doesn't look like Y, something broke. Figure out why."
Nothing is more important in learning any task than learning how to keep learning, and holding someone's hand too tightly might keep them from trying. Sink or swim.
This is the way absolutely every book that aims to teach people a language should be written. When Ruby on Rails hit it big, I picked up two books and couldn't get past the first two chapters.
Why?
The first two chapters were filler chapters. The history of ruby, the history of taking application languages and putting them on the web. An entire quarter of the book in pages was full of back-story, it was chapter 4 before I even saw any code, and chapter 6 before the actual instruction even began.
I will certainly buy this book, and if Zed produces any more about other programming languages in this format, I'm buying them too.
Thank you, I hope it works out that way. I may do other books, especially since this is turning out to be easy enough to do. First though I need to write this one.
From my experience, the coolest thing to do when beginning is to work with a GUI because you really have the feeling to do something great (contrary to print hello in a terminal which is more than useless (from a novice point of view, of course)).
So, my suggestion is to put a small bundle library with a main.py to modify and learn. For instance, that library could only show a simple dialog which you can draw and fun with it.
And the exercice might be more about:
- Print the current time in this GUI (which might be useful)
- Create a small game (such as guess the number, lower/bigger),
- Generate a close-me button that move when you try to aim on it.
Etc.. you get the point: easy and fun exercises.
Finally, there are software which abstract the terminal and merge the editing window with the interpreter. I think this might be way better than saying: try to find the terminal, learn to create a directory, etc.. Why not creating the directory directly from the explorer if the user wants to? More particularly, when you start learning something, everything is new. So it's important to separate the concept of what you should know and what you are supposed to learn. So by this respect, creating a directory shouldn't be part of the same as creating a .py file and writing something in edit for instance.
That's my 2 cents. Good luck and have fun with that :-D
While I admire the desire to immediately get a new programmer productive and into the industry where they can be a useful member of society, what you suggest would be for much later in their learning.
Interesting idea. Each lesson you could learn something and apply it to incrementally build an "interesting" program. In the end you have learned the language and have actually created something.
There's a long tradition in ex-USSR math schools and math department of "teaching by doing", or by solving to be more precise. And I think it gives superior results given talented and motivated students.
have you ever seen this book?
Before now, I assumed that teaching programming meant giving exercises where students figure out how to piece together the fundamentals of programming languages, and then try to build them up to harder programs. After reading through Zed's PDF, I realize I may have been wrong! If you let people absorb ideas by typing existing programs, they won't need to be taught how to decompose ideas, they'll try new things themselves. To teach game programming, you don't need to teach every single fundamental and build the user up to making a full fledged game. You just need to get them to install PyGame and draw a rectangle that they can move with the keyboard arrows, and tell them where the documentation is. Anyone who is really interested will do the rest themselves.
Interesting. Having read the PDF I think this could do well. I did think that it was unfairly skewed toward Macs. I know Zed mentioned in the PDF that later versions would be more Windows/Linux friendly - I guess there's just a need to try to keep things as agnostic as possible to minimise the effort. I'd be happy to help with the Windows side where I can if there's alternative stuff that needs writing for what is likely to be the majority of users.
It might also be worth considering using PyGame later on if there's an interest in creating more visual programs. I know that it's important to maintain the interest of people, that's why a lot of the awesome 80s type and run books would include graphical programs. Again, I'm happy to contribute where I can.
Had I had this book when I was ten or eleven I think I would have been the happiest ten-or-eleven-year-old in the entire world. Like many technical things, programming is typically either self-taught or taught horribly; this seems like a completely reasonable attempt to do it right.
Especially since every kid these days knows how to look stuff up online, but almost no adults know how to teach them how to program from scratch.
- Change the book title. If I see it on a shelf I wouldn't pick it. "Easy Python", "Python: First Steps", "Become a Pythonista" or something more approachable to the unwashed.
- PDF sucks for online reading. Big time. Make it one huge html file, no page breaks, no headers and footers on every page, it sucks. Epub may be a good choice but I rather use one single html file.
Make this one option. The other option should be one HTML file per chapter (or subchapter, or thereabouts) for the people who want to use the browser's bookmark functionality to pick up where they left off.
> no headers and footers on every page
Footnotes, OTOH, are fine if you make them links in both directions (to the note and back to the body text). Both HTML and PDF can do this, and it makes it so much less of a pain in the ass to actually read the things when you know you won't get lost.
I really like this idea of learning things the "hard" way, of doing something and then figuring out why without a lot of handholding. I think it works for beginners, but it also works equally well for experts -- for instance if I'm learning a new language I'd rather just do something and figure out why it's acting in the way it is, rather than read through a chapter explaining it.
What I've found is that the best thing for learning programming is something that can run programs, and example programs to run and debug. That's been true ever since I started playing with BASIC on the Apple II. I've also found that dynamic languages are better, since they provide immediate feedback.
I looked through what he has written so far and it seems to be really nice. I might give it a try as I have no experience in Python (my only programming experience is writing simple Bash and PowerShell scripts). I do, however, wish he had made it available in HTML as well as PDF.
Textbooks do seem to exist as if the Internet weren't usable, don't they? At most they seem to have a few URLs to the publisher's and author's websites. It's actually kind of sad, as if textbook authors didn't trust themselves to outdo what people can find online. Zed does not seem to have that problem.
I have to admit that I find Zed's comments about DiP to be spot on. I hate saying that, because I actually have a favorable opinion of both Mark Pilgrim and his blog.
first, the left and right operands are ordered differently. on second glance, this smells like gray code, so only one operand changes to the next line. nevermind my reaction here.
then, the NOT AND table contradicts what python evaluates the forms to.
I decided to learn Python recently, and I ran into "Dive Into Python" as a recommended resource (I think I Googled "Python book"), and it almost did put me off the language. It's not really the author's fault, it is the fault of those who recommend it.
I remember trying to read it way back when. It came recommended as 'the book' to read about Python.
Besides the ODBC stuff etc. that Zed comments on (never dived into the book that deeply) its biggest problem is that the writing style is extremely, annoyingly, time-wastingly redundant.
I remember it explaining the same stuff over and over, worded slightly differently, easily spanning a dozen pages for every simple thing. After the n-th "I got it the first time, move on!" feeling I stopped reading it.
I'm in the same boat. I really tried to make use of it to learn Python, but it just spends a lot of time going into detail that an interested reader should be able to infer by doing exercises.
I'm actually a big fan of that kind of writing, and I tend to write in that way myself, but it doesn't work for "intro" or "tutorial" books. Jon Skeet's "C# In Depth" is a good example of a book that spends time making sure you really understand a concept six ways from Sunday, but that's the advertised point of the book. When it comes to learning something like a new language, I think Mr. Shaw's on to something, but to be honest I'd rather see sets of exercises like this become a wikified, edited-for-quality community project. The examples in the sample PDF are geared at beginners, but there's no reason that a larger set of simple examples and drills couldn't be created by topic (here's how to do stuff with databases; here's how to ping a server; here's how to talk to a web service) for more experienced users that grok the language and are more interested in learning the libraries.
Anyways, the thing I like about this idea the most is that it puts you in front of a machine with programming tools and has you make progress by doing things, not by reading prose.
No he trashed DiP first, and then was inspired to work on something better. I'm not thrilled with the way he expressed his dislike for DiP, but good on him for working on an alternative.
I agree. There's not many people who put their money where their mouth is. Regardless of how people feel about him personally, he's a very talented coder and has a lot of experience in this domain. I'm excited to see where this goes.
But backticks are valid python syntax, but relatively unused, these days. The contents of backticks are evaluated, and the result is returned as a string representation.
