After spending several days while meddling with ExtJS 4 to grok it, a question occured to me:
What does HN users do when they start to learn a new computer language or framework? Do you "memorize" the reference manual, or what?
Thanks!
It seems a bit large though -- roughly 600 lines of code, average. So that suggests a project of about 200 lines would probably be nearer optimal for learning.
1. Borrow an introductory guide that is targeted at people who've programmed before, and read the first 2-3 chapters. Return it to whoever you borrowed it from.
2. Sit down at computer and start to write code. If you get stuck, visit reference manual, and follow it through until you are un-stuck.
3. (For C/C++ programmers) Assume there is somebody constantly looking over your shoulder at whatever you're doing, and telling you that there's a really simple library call that will do all of whatever you've just done, but in one function call. Then assume this notional person is right, and go and find it.
4. GOTO 2
Do:
- Find, learn your way around and generally become quick at using some kind of computer-based reference manual that is full-text-searchable and well-indexed, because you'll end up using this a lot.
- Familiarize yourself with relevant code browsing features so that you can quickly visit source code for runtime libraries and (where applicable) VM. Then use it a lot to visit the implementations of things and just generally have a look round. This is handy for various purposes, but I mostly use this to find more things to search for in the documentation.
- Ask stuff of people who are familiar with the language or whatever. If they offer you code, put it somewhere where it won't get lost, but don't look at it.
- Locate a copy of the language spec, or what passes for one, and figure out how to read it, so that when something perplexing happens you can tell whether it's official that things should be this way.
Tastes differ, but I avoid doing all the following, so I might be so bold as to suggest that others should avoid hem too:
- Looking at source code other than for runtime library/VM/compiler/etc.
- Copying code from other people, including from runtime library
- Reusing framework code, wizard code or other such junk
- Paying much attention to non-specific advice given on Stack Overflow. (Specific answers to specific, direct questions are fine. General advice... usually ignorable.)
This all probably sounds a bit odd, but it seems to have stood me in good stead.
If you reach for a technical book about some new language, chances are that it will be broken down into chapters, each of which goes into a lot of detail about some specific area.
By reading material like this, you can come away with a lot of specific memorized details, but without feeling like you've learnt anything about the overall topic or are able to put it into practise.
Instead, I like to start at a really high level, asking what problems the technology solves, what is the sales pitch for it, where should it be used and where isn't it appropriate. Understanding things like this give you an angle to learn the technology from.
I'll then drill down a little and try to understand the main concepts. I'll make a few diagrams at this stage, identifying the main components in the technology, and start to question why it works in the way it does.
After that it might make sense to drill into specific areas as and when I need or for reference.
I think it's really important to see the wood for the trees when learning technical topics. The reference details are a Google search away. It's understanding the concepts and making the mental leaps that are the real meat of the learning.
With that said, I believe there is a term used in swimming, and one that I use to explain how I learn new languages - "Total Immersion".
Here's how I do it - open up your favorite reader, and subscribe to a couple of blogs that talk/explore the language that you are playing with. There are usually a few "gurus" that you can follow. Another way to find good people is to put a search for a particular hashtag in twitter. Or join the Google Groups page (if your language has one).
Then every day spend an hour or so reading - initially none of it makes any sense (at least no to me anyway :D) - but I have learned that over time my brain latches on to these "snippets" of wisdom, little tricks in the language that you can eventually "grok" as you learn more about that language. It's these "Ah! That's what xyz was talking about" that really make things interesting.
Furthermore, you could attempt to partake in the conversation (even if you lurk, like I do). People ask all kinds of questions on google groups or twitter - even if you are not confident enough to respond, you can attempt to find an answer on your own. What this does for me is that sometimes it's a small enough question that you can start to delve into and get a better understanding of one particular aspect of the language.
For e.g. recently on the Clojure user Group someone asked "Pretty-print with metadata?" [https://groups.google.com/forum/#!topic/clojure/5LRmPXutah8] - I had never thought about it, but it is an interesting problem. So I sat down to see if I could find a way to do it out of the box. No cigar. So then I wrote a small function to make it happen. Needless to say, my solution was no where nearly as elegant as the ones posted in response, but then I got see where I went wrong :)
Hope that helps. Good luck.
Some languages and most frameworks do not have a reference manual. For those, the challenge is to decide what source is authoritive, whether it is up to date, etc.
I rarely start working with a technology before having read or at least browsed a few hundred pages. Reason for that is that, for me, reading a reference is a more efficient way of getting a feeling of what a language can do than trying it out. Also, if the reference does not exist, chances are it isn't technologically interesting and/or it will not get popular. In either case, the technology isn't worth learning about.
When i decided to learn PHP, i went to the php.net and started learning the "syntax". And then i started "memorizing" the functions. But it turned out i was just wasting my time. Ok, i learnt some stuff of course, but just peanuts.
I decided to change my way. I set a goal; "to make a website". Then started to coding.
In the beginning, on every line i stucked. I asked myself & Google "I need to do this. how can i do it?" For almost every line, i googled for something. By time goes on, it started to take place in my mind.
On every step, i set another goal. When i ask myself "i want to do something like this, how can i do it?" , I started to (had to) learn something on CSS, JavaScript, Jquery.
For me the steps to learn are; 1. Set a goal. Make it hard! While getting to that goal, you'll learn lots of things. And finally when you reach that goal, set another one, more harder.
2. Use Google a lot ;)
edit: typo
A new emerging trend is to learn via websites that give you a task and you write code to perform that task, on the website itself.
One such example [for Ruby] is http://rubymonk.com
- I recently joined a local Clojure group on meetup.com and started attending meetings.
- I know the main web sites for the language, including a great searchable documentation site I use.
- I already know Scheme and Common Lisp, so my focus is on grasping the differences with Clojure.
- I just completed the Clojure koans I forked from GitHub.
- I started reading a Clojure book.
- I have played around with the REPL.
- I have started using a serious development environment including Leiningen.
- I will look into a testing framework to use as I experiment further.
- I have some specific tasks I want to try to implement in Clojure involving concurrency to get a feel for what I can usefully get out of this language.
- I'll look at people's code, of course, to get an idea of good and idiomatic practices.
2. Pick a small part of it you need to implement.
3. Google[insert favorite search engine] for code in your language that does kinda what you need.
4. Move the code around until you get what you need done/working.
5. Repeat 2-4 until you have done your project.
6 Repeat 1-5 on three projects.
7. Read blog articles about how to write properly in that language.
This is basically the formula I used since childhood. The other way around of learning syntax is too boring and tedious. Starting out with projects means at the end of the process you have something to show, and the syntax has contextual clues for easier memorization. Additionally, you incorporate other people's programming habits that took years to develop[you wouldn't get all, but you would get some] .
Keep a reference manual open in a background tab and dive in.
Go to a popular project on Github, go to the issues tab, pick a random issue and try to fix it. This will give you more insight into the ups and downs of a language than anything else. "Pet projects" are stupid as they have no real world use and you already understand most of the logic behind them, solve problems and make things happen.
Once I've done that, it's time to start on a small project. I just start coding and looking up what I need to know. I know in advance that my code will be bad. In fact, the more often I encounter some piece of documentation that leads me to say, "Oh, I should have done it that way", the more I learn.
The idea is to quickly get an understanding for the concepts behind the language, when you dive into the topics you already have a mind map to file them under. This also gives you a feeling for the community.
Next I read the top questions on stack overflow and join the IRC channel on freenode.
By learning from the common pitfalls made by others this saves me from a lot of startup frustrations which would otherwise prevent me from actually using the language.
I grasped Common Lisp with writing `Hash Array Mapped Trie` data structure(one of the data structures lie within some of Clojure's persistent data structures). It helped me understand both the particular data structure and the language.
Choose an interesting project from SourceForge - create something similar.
This is more efficient because you're now learning a new language and domain-specific concepts at the same time.
If I like the first couple of experiences I'll pick up a reference manual and try something a little harder.
Thanks!
Unfortunately, few books approach K&R's quality. I don't like books that are written under the assumption that I will be sitting at a computer as I read them, and expect me to be typing in code and running it for everything they cover.
If I can't find a satisfactory book, I'll cobble together something from what I can find on Safari Library, free online books, and assorted internet searching.
A while back I tried an interesting experiment. I needed to learn some Lua, because I wanted to write some add-ons for an MMORPG I was playing (Warhammer Online). Lua has pretty good documentation, but I had recently read that famous article on digital natives vs. digital immigrants, whose theses was that digital natives (people who grew up in the digital world) have a fundamentally different understanding of technology than those of us who grew up in the pre-digital age and immigrants to the digital world. The natives are multitasking do-ers, who want to learn things as they need them. They aren't, supposedly, like the immigrants, who think the way to learn things is to read a book, then start doing.
I decided to take a more native approach with Lua to see how that worked out. So, instead of reading the Lua documentation, I downloaded and looked at a few Warhammer Online add-ons to see how they were structured and get a feel for what Lua code looks like. I looked at the Wikipedia article on Lua to get an idea of what kind of things the language had.
Then I started coding. Whenever I wanted to do something that I knew the language could do, but didn't know how, I Googles. So, for example, the first time I wanted to initialize an array with literal constants, I'd Google for that.
This actually worked. I don't know if my Lua code is any good, but comparing to what I see on other people's add-ons, it seems in the same league at least. I would not put "Lua programmer" on my resume just yet--I'll wait until I actually read a complete manual before doing that. I did a similar experiment with JavaScript, with similar results.
I'm not convinced, though, that the "native" approach is actually good. Yes, I got satisfactory results, but I think much of that has to do with the fact that I've been a professional programmer for 30 years. That has given me good filters for recognizing bad code, so when I'd Google for how to do something and get back and answer that turned out to not be a good way to do whatever it was, I'd sense that and keep looking. Someone with just a couple years or less experience would probably have incorporated a lot more things from the bad examples on the net.