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.
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.
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.
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.
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.
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!
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. :)
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.
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.
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.
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.
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
"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.
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.
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?
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.
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.
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.
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
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.
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.
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.
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.
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.
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 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.
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.
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.
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."
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.
113 comments
[ 3.4 ms ] story [ 170 ms ] threadFor 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.
Doh! VB index alert: The exercises are 0-based and the steps are 1-based. ;-)
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 wonder what my high school is using, they started us with BASIC, then Java and finally a little C... I was pretty well prepared for first year.
That being said, Python is a wonderful language to get started in programming.
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.
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.
Also, there will be a few jokes about cardinal vs. ordinal numbers.
FWIW I didn't watch the videos, I just read over the webpages.
http://code.google.com/edu/languages/google-python-class/
Looking forward to reading Zed's book too.
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.
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 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.
The design/typography kinda sucks though, of course even Zed has pointed out how hard it is make a good looking code book.
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.
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.
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?
I know a few people I might be able to talk into it. If I do, I'll report back.
http://openbookproject.net/thinkcs/python/english2e/
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.
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. :-)
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.
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.
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."
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.