How do you learn?

I think the idea of staying in a tight edit/test loop is good too. I tend to make lots of typographical/syntax errors that can be a nightmare to debug if you're having to scan many lines of newly written code. If you're only writing a few lines at a time and then testing, finding errors is much faster.

Also, when you use a "obscure" language like lisp the documentation is often subpar/incomplete/obsolete/lying/whatever so sometimes the best it can bestow is a false sense of knowledge (which fortunately is somewhat useful to get started).

For Scheme, I read SICP, of course. For Java and C++, Bruce Eckel. For Ruby, _Why followed by the Pickaxe. For Emacs, I read Learning Emacs, a very good book. I even learned Perl from a book, although not the Camel book, which is torture to read -- I used Randal Schwartz's Learning Perl, which was very good. I learned CSS by reading Eric Meyer's O'Reilly book, pretty much cover to cover, as well as Dan Cederholm's book. I learned SQL (and Tcl as well) from Greenspun's books (e.g. SQL for Web Nerds) which weren't really dedicated and pedantic SQL tutorials but were, in a way, much more useful.

Of course, I'm the guy who got bored with BASIC as a kid and decided to teach himself Pascal. So I read a few books on Pascal. Unfortunately, we didn't own a computer at the time, and the library didn't have a Pascal compiler, so I didn't get to compile a Pascal program until two years later. So maybe I just got into that habit early and never really lost it.

Of course, you can't actually learn a language from a book. You have to practice a lot to get the syntax and the semantics and the idioms into your fingers. So it's just a question of whether you do the reading first, or second.

There are quite a few exceptions to my usual rule. I know a bunch of C, but I never read a really good C programming book. Of course, that means I get to look forward to K&R, which is nice. :) I probably learned as much Perl from randomly hacking as I did from Learning Perl. I still haven't gotten far through Mastering Regular Expressions, though I've used them for years. I have yet to find a really great book on PHP (to everyone's astonishment, I'm sure) -- the O'Reilly book is okay, but I keep getting bored. And for some reason I cannot make myself read any docs for jQuery. It's so sensible that I can't concentrate on the docs; it feels like a language that I already know!

Technology is changing things. I normally hate learning from lectures -- talking is just too slow, and you can't skim it -- so I was surprised to discover that podcasts and screencasts about programming are actually quite useful. There are aspects to being a good programmer that are best learned by watching over someone's shoulder, or listening to them ramble on about their most-favored and least-favored tools. And then, you know, there are blogs and news.yc.

Programming is similar. We make mistakes and brute-force our way through. We start to recognize patterns. That's experience. It's a lot easier however (even though it's all in the head) to do fail in something if it's only you and the compiler/runtime (who cares if it doesn't work right away, you know it will) - when other people are involved, it's a lot harder (fear of what people think)

Then I found Python and Django. Now I just kinda type... 7/10 times I'll get it right, which is a great feeling! I also read a lot, and often find little gems in books that I wouldn't have picked up as quickly by tinkering.

Nobody can teach or no mechanism is a good thing if you are not willing to learn and likes it .

So... what is the best book to learn python? :D

Also, learning is like birth and death: there might be other people in the room, but you do it alone. Learning is an experience, not the result of reading something. You can understand what you read, but understanding an idea != learning.

For example: When I was learning Perl, I first read about "make repetitive tasks easy", "good text processing", and then got hacking. When I was learning Lisp I read about macros, recursion, list-processing, and then got hacking.

One thing I've come to understand: you only learn when you are asking questions. Reading a book doesn't put you in the frame of mind where you're asking questions. You are being spoon-fed information, sometimes before you know why you need it. The information might be useful or vital, but if you don't know you need it or why you need it then it won't stick.

In particular, learning -- creating knowledge -- consists of creating something complex (an idea in your own head) that didn't already exist.

How complexity could come about is a famous question. The original answer was via a designer, but that begs the question, because either the designer already contained the complexity in question, or had to create it (somehow).

But now we have a better answer: evolution. And that is how people learn.

Evolution consists of imperfect replication and selection. In thinking terms, what you have to do is think of lots of ideas, subject them to criticism, and then think of (hopefully improved) variants of the surviving ideas, then more criticism, repeat, etc

This is important to know because being open to criticism is more important than people realize. It's generally considered a good character trait, but it is in fact absolutely fundamental to learning anything.

I think just about every language I have mastered has been because I started learning it by hacking on someone else's code. (mastered = know well enough to implement projects from scratch with ease) I would say I 'know' probably a dozen or more languages enough to read/write useful code, but have only mastered maybe five... and all of those because I spent a lot of time dealing with existing code, so I learned by toying with it. Sadly if I don't use something for quite a while (like Scheme, which I used to live and breathe, but haven't used in probably three years), I become pretty rusty with it, but I suspect this is normal.

My current languages of choice are probably Ruby, JS, and Arc (for the fun factor). I actually learned ruby because I didn't like Rails, and tried for a while to write my own framework, before discovering Merb and tinkering with it instead. JS always scared me for some reason, but I finally picked it up because I wanted to use jQuery and ended up tracking down bugs in their UI stuff. Arc I am learning currently, just by playing with stuff submitted by others.

So in short, I learn by modifying other code, and eventually get comfortable enough that I can just write from scratch. I actually like the book examples, because they put the finished code online. I don't even bother reading the chapter where they explain the code... I just load it up and start tinkering and learn from that.

First, this familiarizes me with the language constructs, what is and what isn't available, and I can build up a "mental diff" of how this new language is or is not like other languages I already know.

Perhaps more importantly, it also gives me a clue as to if I should bother spending my time to really learn the language well. For example, I've tinkered with Ruby, and read some Ruby documentation. It appears to be a fine language, but I don't see it offering me anything that I find lacking from Python or Lisp. So I've never taken the time to become expert with Ruby.

Tip the lego out and play around with the interesting gears and see what you can do. Throw away the manuals that tell you how to build exactly the same car that everyone else is building - obviously skim through them, or look at them every now and then to see how things can fit together. Sure find out from somewhere how a differential gearbox works, then play around trying to build one.

I like to have the manual for reference - 'The definitive javascript', or the ARM7 manuals or whatever reference is needed, and sometimes dip into those in the bath or before bed. But 'learn the language' books don't seem to make much sense to me.

Exploring is so much more fun than "designing using approved methodologies like everyone else is, using the same framework/libraries as everyone else is". IMHO you're likely to end up with a far better result as well.

I just don't understand people who don't have that tight feedback loop. People who write a program from scratch in one or two hits, then execute it. That's like recording yourself playing a piano concerto with earplugs in, then listening back to see if it sounded ok. Better to have the feedback earlier so you can adjust.

I have to have something practical, something that I want to use either personally or at work. And at first it has to be pretty simple. If there is no low-hanging fruit to explore I'll probably get bored and move on (i.e., fail).

I like to learn about the right way to do things in my given environment and am terribly afraid of people with more experience than me seeing my code and mocking it.

You make it sound so familiar with I'm passing through. I love Flex and it's potentials!

Whenever I have trouble figuring out how to do something, THEN I refer to the documentation.

Maybe I do it this way because I have never met a language that didn't have 10 times as much stuff as I needed.

Teachers can present angles you don't think of yourself though, so sometimes its important to get other opinions whether it be from other programmers or whatever. I know that even after programming a ton I learned a lot from a simple intro to compsci class.