14

One type of question that keeps coming up on Programmers.SE is how to learn a specific language, given you know several others (usually through a lot of experience or education).

In some cases, however, one might need to get up to speed quickly for a job, or for personal development, or even to check out a hot new platform.

In your experience, what general strategies have you used to pick up a new language quickly? Are there specific aspects of a language you try to focus on when starting cold? What types of resources do you find helpful in this process?

5
  • 6
    I would say just do it. Official documentation and Google are the only resources you'll need.
    – Fosco
    May 21, 2011 at 19:35
  • @Rein Some of the answers overlap, but the goal of this question is to build up a canonical answer to learning a language (any language) as quickly and efficiently as possible. The other question is a mixture of book recommendations, similar answers to the ones given here, and general advice on non-rushed learning (reading just before bed, reading the language specification, taking weeks to become familiar on a basic level with a few different languages).
    – user8
    May 21, 2011 at 20:29
  • I'm not sure how useful the question as asked is. If I know several programming languages, I've probably learned how to pick up a new language, and probably efficiently. If I don't, how am I going to benefit from this question? May 23, 2011 at 20:54
  • 1
    @David I know a half-dozen languages, but I've learned them usually after either taking classes in them or after several months of work. But if I have to pick up a language quickly for a new job on the other hand, that doesn't help me. I don't doubt people who have learned several languages have picked up ways to learn them quickly: that would be what I hope the answers contain.
    – user8
    May 23, 2011 at 21:00
  • @Mark Trapp: Thanks, that clarifies things for me. May 23, 2011 at 21:08

8 Answers 8

18

I've found the best way to learn a new language is by doing, not just reading. And so, when I want (or need) to learn a new language, I generally do read a few chapters of a reference book on syntax, but then I dive right in and create something, rather than reading and reading book after book.

I've found that as problems and questions arise, answers are found (often on the internet). I also think this is why on the job training is so valuable, because you are producing a work product most of the time, even if it's a draft version - and so you are learning by doing.

I encourage people to just think of what interests them, and dive right into writing code or creating forms, etc.

Later on, after you have created project after project, a good reference book will teach you the fine details that at this point, you more easily grasp.

Also, the projects generally start out smaller and grow in complexity - from the simple "Hello World" app to a small and not very useful project, onwards to a full app. In terms of what aspects of the language I focus on, it depends on the applied use of the language - I never learn every API or framework to start (like with .NET for example). That would take far too long. I learn the core syntax, then branch out from there, researching each extension as needed. With a less modular language, like CSS or XSLT, I simply learn the most popular constructs first and add others as needed.

3
  • When you say "just do it", are there specific aspects of the language you focus on when diving in to make sure you pick it up as efficiently as possible? Or do you just keep doing random sample projects until it "clicks"?
    – user8
    May 21, 2011 at 19:38
  • Well, the projects generally start out smaller and grow in complexity - from the simple "Hello World" app to a small and not very useful project, onwards to a full app. In terms of what aspects of the language I focus on, it depends on the applied use of the language - I never learn every API or framework to start (like with .NET for example). That would take far too long. I learn the core syntax, then branch out from there, researching each extension as needed. With a less modular language, like CSS or XSLT, I simply learn the most popular constructs first and add others as needed. May 21, 2011 at 19:43
  • 2
    can you add that back to your answer? That's some great information.
    – user8
    May 21, 2011 at 19:48
5

This works for me:

  1. Read about it.
  2. Use it.
  3. GOTO 1.

For the read about it step I try to pick "the" reference for the language. E.g. "The C Programming Language". It needs to be condensed, to the point, and build your knowledge incrementally. Then I read it cover to cover. I'm a fast reader and I don't dwell in this first read. Then I'll go back and refer to specific points as I'm trying to use the language. What I'll probably spend more time on is code examples inside the book.

The first thing you need is the syntax. Without knowing if it's BEGIN or { or block indentation, or how you declare variables, you can't write anything. The author will usually introduce the more important parts first or will have a tutorial that covers the basic usage of the language. It's hard to give more general guidelines because some languages are very different than others. The next thing is getting a general feel for the language, what is the overall philosophy, how you approach problem solving within the context of the language.

Another thing to keep in mind is the "use it or lose it" concept. If you haven't used a language in a while it will take you some time to get back to speed (though that time will get shorter with experience). Once you got the language's syntax you'll need to learn about libraries etc.

So it's an iterative process. Going deeper at each iteration. Never ending. Even after using a language for 20 years there's still something to learn.

2
  • Can you elaborate more about what you mean by "read about it"? What, specifically, do you focus on when you start to read about a new language you want to pick up?
    – user8
    May 21, 2011 at 20:32
  • @Mark - see my edits... Is this what you're looking for?
    – Guy Sirton
    May 21, 2011 at 20:44
5

Grab a real world project

The way I see it, it is easier to learn something when you actually need to learn it. For me it was with javascript, where I risked it by accepting a big project with a two month timeframe. It was me there every day and every night trying to achieve results for this freelance project, and by 1 and a half months the project was done.

I also accidentally learned some SQL there, then I finished learning it in college, and guess what, I had an easier time too.

If you don't want to risk it...

The actual key to the previous point is to solve real world problems... but I work better under stress (I like stress, I think it is fun and I might be damaged, so...). If you don't, just go after an open source project that interests you and uses the language you want to learn and try to contribute. If your code sucks, you might get some feedback depending on the community.

Chances are that you will make progress just by studying the code.

Get all the reference that you can

That includes several books, official documentation and all the reference that you can get. Chaces are that, that way, you will know how to do the same thing different ways.

Other communities —like forums, mailing lists, and here— also count as reference.

1
  • I would add "grab a hard real world problem". Pick something that requires you to get neck deep on tne first day. My first day with C# i was figuring out how to dynamically load dlls, use reflection to get the classes, and from that a list of mehods. I learned a ton tha day, having never used any .net technology before. Sep 26, 2011 at 23:33
2

There are lots of ways to learn a new language, but not all are equally efficient. I found these three guidelines work best for me:

Make a map of what you don't know

Figure out, in advance, what you'll need to learn. Find an overview or general documentation source that describes the language in abstract terms. From that, you can usually get a fairly complete overview of what the language is about. Use that overview to highlight areas that you don't know, but are considered core to the language. Is tail-recursion a concept you need to learn to really grok the language? Maybe you'll need to know your regex much better, since the language specializes in string manipulation. Or, maybe you'll really have to get your Algebra on, since many of the concepts in the language map directly from algebraic concepts.

Get good resources to help you learn what you don't know

You might want to get a good reference on Algebraic formulae, or maybe you'll just want to buy "Javascript, the good parts". For some learning curves, this work has already been partially done. If you're trying to learn C# from a Java background (and vice-versa) there's a litany of blog posts and websites that map out the differences, and contain references/resources to help you learn.

Make sure that the resources are not just references - make sure they include tests or exercises to help you assess whether you've learned a concept properly. Reading about tail-recursion is one thing, groking how it's implemented in your language of choice is another.

Build something real

It's almost impossible to do any sort of real learning without a tangible goal in mind. This is especially true of applied arts - which is what programming language use is. Make sure you have a real target to aim for - building something is usually the best choice.

1

Identify the Programming Paradigm(s)

I usually identify what the primary paradigms for the language are. I think of problems differently depending on paradigm.

Identify the Idioms

All languages have idioms. Idioms vary in size and scope from how you structure code, all the way to particular code fragments. You should always try and use a languages idioms.

Write code

I usually write some functional code. Anything from a Primes Sieve to toy web apps. The problems I choose are usually specific to what I intend to use the language for.

1

Just dive in!!

Considering you already know how to program and know several languages, except if that language introduces a very deep paradigm shift, I'd say (concurrently):

  • find a pet project to drive you,
  • and on the side program some puzzlers

Learn, Practice, Apply (until satisfied)

The classic 99 Prolog Puzzles (here, the 99 Puzzles in Scala) or the Project Euler are usually good places to look for small puzzlers to re-implement. Or lurk around StackOverflow and re-write some nice answers in your target language, trying not to do a line-by-line rewrite but something that captures the essence of your new language.

Learn with the puzzlers, read blogs and essays on the side to get a deeper understanding of the language and get a feel of the tooling and the holy wars of your new community, and write your test project to apply your new found knowledge and skills and see what road-bumps you run into.

Speaking of Community...

Share and expose yourself. (Not too much, though.)

Maybe you also want to visit a local user group, find buddies to code with (to get some constructive criticism and not lock yourself in a specific mindset), and subscribe to that scary IRC channel or mailing-list where they drop strange words about AST trees and write philosophic tirades about how monads are not monads and how once you've met some strange girl you cannot go back.

0

I know this sounds lame, but start coding something, even if it is silly, and use lots of Google for things following this pattern:

how do I do [something from one language] in [another language]

If the words are common use quoted literals.

It is a common enough question that pretty much the only times I don't find an answer anymore is when I find a page that explains why it cannot be done.

0

As a specific suggestion for just using the language:

Fix Bugs

  1. Find an interesting open-source project in the target language, preferably one with a public bug tracker, moderately active development, and a decent test suite.
  2. Pick a bug to fix, preferably one that annoys you when you actually use the program.
  3. Figure out why the program exhibits the buggy behavior.
  4. Write tests and code to fix the problem.
  5. Submit a patch upstream.
  6. Revise your patch until the upstream developers are happy.
  7. Go back to step 1 or 2.

This process tends to be more fulfilling than writing yet another toy program, but much easier than starting your own full project from scratch. You get exposed to some of the language idioms in their natural context, and (with any luck) someone's idea of what good code looks like.

On the other hand, it can also be extremely frustrating, particularly if you pick a nasty bug, or if the developers reject your patch without properly explaining why.