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.
"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 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.
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.
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.
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.
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.
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.
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.
[+] [-] pavelludiq|16 years ago|reply
[+] [-] zedshaw|16 years ago|reply
[+] [-] unknown|16 years ago|reply
[deleted]
[+] [-] projectileboy|16 years ago|reply
[+] [-] fretlessjazz|16 years ago|reply
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.
[+] [-] phren0logy|16 years ago|reply
I'm sure there are other, similar options but TextMate has been good to me.
[+] [-] zedshaw|16 years ago|reply
[+] [-] code_duck|16 years ago|reply
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.
[+] [-] steveklabnik|16 years ago|reply
Get used to programming first, then use better tools.
[+] [-] callahad|16 years ago|reply
[+] [-] zedshaw|16 years ago|reply
[+] [-] ivenkys|16 years ago|reply
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.
[+] [-] simonista|16 years ago|reply
I know a few people I might be able to talk into it. If I do, I'll report back.
[+] [-] zedshaw|16 years ago|reply
[+] [-] petercooper|16 years ago|reply
http://cacm.acm.org/blogs/blog-cacm/45725-how-we-teach-intro...
I'm on the fence. I see the music-style logic to picking things up and working on the practical stuff right away, but, hey, studies are studies.
[+] [-] zedshaw|16 years ago|reply
> 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.
[+] [-] codyrobbins|16 years ago|reply
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.
[+] [-] pgbovine|16 years ago|reply
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
[+] [-] motter|16 years ago|reply
http://openbookproject.net/thinkcs/python/english2e/
[+] [-] zedshaw|16 years ago|reply
[+] [-] tel|16 years ago|reply
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.
Great start, Zed.
[+] [-] iamdave|16 years ago|reply
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.
[+] [-] zedshaw|16 years ago|reply
[+] [-] DannoHung|16 years ago|reply
Did you try reading the PickAxe or Why's Poignant Guide?
[+] [-] d0m|16 years ago|reply
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
[+] [-] cdr|16 years ago|reply
[+] [-] zedshaw|16 years ago|reply
[+] [-] steveklabnik|16 years ago|reply
[+] [-] anujseth|16 years ago|reply
[+] [-] migiale|16 years ago|reply
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?
http://www.amazon.co.uk/Algorithms-Programming-Undergraduate...
it would be really cool to have a book of the same level for python.
[+] [-] rabidgnat|16 years ago|reply
[+] [-] _b8r0|16 years ago|reply
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.
[+] [-] julio_the_squid|16 years ago|reply
http://homepage.mac.com/s_lott/books/python.html
[+] [-] Avshalom|16 years ago|reply
The design/typography kinda sucks though, of course even Zed has pointed out how hard it is make a good looking code book.
[+] [-] jcdreads|16 years ago|reply
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.
[+] [-] Kilimanjaro|16 years ago|reply
Now to the critics:
- 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.
Good work!
[+] [-] chbarts|16 years ago|reply
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.
[+] [-] overgard|16 years ago|reply