Zed Shaw is Writing A Book Teaching Beginner Python
sheddingbikes.com
sheddingbikes.com
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.
I'm sure there are other, similar options but TextMate has been good to me.
Get used to programming first, then use better tools.
Other than that, there's SciTE, which is quite nice. Notepad++ on Windows is a derivative thereof.
no, really.
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.
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.
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."
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.
I know a few people I might be able to talk into it. If I do, I'll report back.
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.
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.
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.
> 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.
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."
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
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.
I'm building a list of free books for people to move onto after they finish mine. I'll put yours in the list.
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.
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.
Did you try reading the PickAxe or Why's Poignant Guide?
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
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?
http://www.amazon.co.uk/Algorithms-Programming-Undergraduate...
it would be really cool to have a book of the same level for python.
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.
The design/typography kinda sucks though, of course even Zed has pointed out how hard it is make a good looking code book.
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.
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!
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.
Awesome! Not your usual textbook exercise.
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.
My girlfriend asked me to teach her Python - she's doing her masters in statistics, so she's coming from an R/SAS background.
Apparently Python is useful to know in the investment banking arena, which surprised me.
But, tell your girlfriend that if she ends up working for a bank I will cry and take my book away from her. :-)
I think an example like:
print "hi there", "how are you"
with a brief explanation of the argument structure of print would be helpful.
This makes me want to write a tutorial.
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.
the NAND and NOR tables don't follow the same evaluation scheme.
the NOR table is "(not A) or B", which is according to python's precedence rules without parentheses.
the NAND table is "not (A and B)", which matches the common definition of NAND.
But no, I don't remember much about the book, I can't really comment on its quality.
When you compare that to Dive into Python the choice is easy ;-)
Either that or javascript becomes mainstream server side.
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 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.
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.
>>> `1+1`
'2'