Ask HN: What is your best way to learn a new programming language?

Watch YouTube videos

Other than practice? Read a good book on the language. You can also watch Udemy courses.

Yes. I usually do one or several projects to learn how a new language works. The projects I do depend on the language. I hate reading books and even moreso watching videos about a specific programming language, but thats prolly just my ADSD self.

Here's a project I'd do for Swift.

1. Write a chat server / client. (this will quickly let you see how async/threads/channels works and how good the networking libs are). You can easily go further and add a GUI to see what thats like. Add Sqlite for managing contacts/settings to see how the db layer works.

2. extract things into libraries/modules/packages i.e.whatever swift calls it, to learn how their pkg and version mgmt system works.

3. As soon as you have something working push it to a server and get it running. Add a bash script to do this automatically. The goal here is to learn how to actually release and deploy using swift.

It doesnt have to be a chat app, I usually do something thats like a problem I'm currently working on, and its best if you can actually use it to solve some real world problem. It just needs to be something that has a lot of places where you can explore parts of the language i.e. db,networking,async,etc.

I had the same question when I wanted to learn C++. I was already quite practiced at Java and had written C and had read books on C++ off and on for years, but I still could not program in C++.

So I got a copy of Stroustrup "The C++ Programming Language" and started to do his exercises, but the author clearly had never done them himself, some were quite long and tedious and did not teach me anything (never put exercises in a book that you have never done), so I gave up on doing his exercises.

In my exasperation I just made up my own exercises: I just started at the beginning of the book and for each feature the book mentioned I wrote a little program that used it. The book said you can throw any kind of object, including, say, an int, so I wrote a program to throw and catch an int. I have never done that before or since, but I did it. I wrote a little program for every feature of the language. It was incredibly tedious, but it worked.

I also compiled every program with two C++ compilers and ran them and compared the difference. Many of my little programs did different things in the two compilers (!). I coded for 10 hours a day for two weeks; when I was done, I could code in C++, I could think in C++. Don't despair if it takes you longer: recall that I was already an experienced programmer.

SECRET SAUCE HERE: The key here was to actually write the program even if I was sure I had nothing to learn from it because the feature in question was so conceptually simple: you think you know something, but then when you go to actually type it in, you find out whether know it was well as you thought you did. The tiny improvements you make while doing this copy-check-repeat feedback loop is the essence of learning the skill.

Note that no mistake is too small to be worth correcting. It is critical to not say you have passed the exercise until you can produce the result exactly and reliably, as a matter of course. If you just wrote a program and it was easy, then hide it and write it again.

At one point I was embarrassed that I could not write makefiles, so instead of copying them and hacking on them, every time I needed one I wrote it from scratch; now I am a master of gnumake. I repeatedly write fizz-buzz, binary search, heapsort, hashtables, etc. over and over, just to make sure I can do it correctly and without effort.

One of Richard Feynman's wives left him, legally accusing him of spousal abuse because he did too much c1alculus: https://www.theguardian.com/science/2011/may/15/quantum-man-... '"He begins working calculus problems in his head as soon as he awakens," Bell complained to a divorce judge. "He did calculus while driving, while sitting in the living room and while lying in bed at night."'

Ben Franklin describes using this method in his autobiography of how he taught himself to write. He dropped out of second grade and ended up as one of the best writers in American history (not to mention scientist, statesman, engineer, etc.) He says he found writing he liked and practiced copying it and then checking that he had copied it correctly; see his autobiography for more.

Woz used this method to teach himself how to build computers: he had the designs of computers from Silicon Valley firms and he just practiced rote copying the designs over and over.

I tell you this as a former graduate student in Mathematics at Berkeley: The secret to learning is not reading a bunch of abstract ideas. The secret is just running a huge number of examples through your brain; your brain then abstracts them for you. There is no need to study a bunch of abstract rules. After you have learned the skill this way, doing a "master class" with an expert where you return to what you have learned and examine it, thin...

Usually I’d suggest picking up a small project and shuffling between books and working on that project. Say read about the language fundamentals and then try to build up from there.

However this doesn’t really work when you’re switching to a different paradigm. When I switched to Haskell, I realized that even the way you think about things must change and diving into a project just isn’t the way to do this. You’ll keep stumbling the entire time if you bring your imperative mindset with you and attempt to leverage off them to get a quick start.

If you don’t have some functional programming experience under your belt, first spend some time familiarizing yourself with the language history and try to figure out why some design choices were made. Try and soak up as much theory as you can by getting the best books on the language. This is much slower but you have to bear in mind that sometimes you have to unlearn several things that may be considered a bad practice in the previous languages you’re familiar with.

I try to treat learning a new programming language like learning a new human language. I know quite a few and it’s always easy to fool yourself into thinking that once you know the syntax and grammar for a similar language you can port them over to the new language. You’ll be surprised to know some languages don’t have some words at all based on their culture and have no way to express something that is easy to grasp in English.

So long and short, history and some theory about the language first, then dive into a small project, pick up another book along the way and then more theory.

Read the docs, read good code, build things, stackoverflow, ship.

Lots of different techniques.

1. Write a program in the language that I've done before just to get familiar with the tooling. My go to for years was a better Eliza clone. From 1991-2008, I wrote it in AppleSoft Basic, GW Basic,HyperCard, VMS DCL, Visual Basic, C#, PHP, and JavaScript.

2. On the job. I hate hobby side projects. I'm not creative enough to come up with anything interesting and I feel like it's a waste of my time to build something that will never get used. I would rather just work on a proof of concept related to my job after hours and show it during a lunch and learn. I get real feedback from peers and if it's implemented, I get to "productize it" and see it in the real world.

3. On the job (part 2), I'm at a point in my career, where companies will hire me if I only have half of the required experience in the technologies they use because I've worked at a lot of small companies where I've led projects either officially as a team lead or unofficially because the team was so small I could take the lead. I can usually get a job based on what I know well and they give me the opportunity to learn what I don't know while doing a project. I'm more than willing to put the time in to get familiar with a technology I don't know.

4. PluralSight - I'll watch videos to get an overview of a technology usually before I go to work in the morning while working out in my home gym.

5. Certifications - I don't believe most certifications are worth it from a career standpoint and when I'm hiring, I take many of them -especially developer certifications - as a negative signal. I wanted to learn C# in and out in 2008 when I was transitioning from 12 years of C/C++, did a combination of 1-3 and did the highest level of MS developer certification that required 6 tests. I never put the cert on my resume or talked about it during an interview, but it forced me into an organized learning path.

I'm working on my AWS certifications now for the same reason - to force me into an organized learning path. But I will put these on my resume, they seem to carry weight - especially at consulting companies.

For me, it's always writing an actual application...no toy or example programs. I suggest rewriting something you've implemented before, rather than new. The reason for this is that you've already solved the problem, you're just left to language semantics. Trying to tackle a new application is fine, too, but may cloud your judgment on the language if it becomes a hard problem to solve, or just plain boring.

I usually write something small that I've written multiple times before. I try to write it exactly like I would in whichever my currently most-used language is. It gets really painful in parts because languages differ. Sometimes the writing is the difficult part. Sometimes writing it in the same way is easy but the runtime performance is bad. Sometimes the tooling just doesn't support what I am trying. Finding these pain points helps me develop an intuitive sense for which of my habits I should steer clear of with the new language. After I consider how the new language would allow or encourage me to write it differently, I re-write it. Then I diff my original and final implementations.

It helps to have a stock project or two that let you exercise I/O, data structures, standard library, benchmarking and so on.

For me I have a couple:

1) A nonlexical phrase extractor. Read in a lexicon of words, read in a narrative document, subtract words from the lexicon from the document, collect all remaining strings with word length > 2. Voila, most of them will be names of people.

2) Build an on disk bloom filter. Pretty straightforward, the most complicated part is finding suitable hash functions and figuring out how the local mmap library works and working out the arithmetic for bit flipping amongst a big array of bytes.

Neither of these are very complicated or require lots of work to set up. But when you're done you'll know most of the operators, how to read in and write out things, how to interact with the standard library, control flow and so on. I can usually hammer both of these out in an afternoon.

A few people I know have more advanced "simple" projects, like ones that require figuring out the local threading system, sockets and so on: e.g. write a simple web server. It kind of depends on what kind of work you generally do.

It's really pretty straight forward, I pick a simpler project from my list I'd like to do that seems like a good fit for the goals of the language, then I write it in that language.

Problems and friction are exposed pretty quickly, but you have to push through those to see if the good parts of the language make up for them. I find that if, after a short while, I don't have to force myself to write the code, and if I can dream up ways to solve any problems I encounter without turning to the documentation, then I've found a really good fit. Sometimes you find that the initial friction was largely just a matter of coming from another language's mindset.

If you find instead that you're not wanting to write code, that you're spending a lot of time fighting it or scowering the documentation or getting the build to work, then my opinion is that the language isn't worth learning anyway so it's best to move on.

If you're interested in Swift just for Swift, then I would recommend against learning Swift through iOS development (just in case you were thinking about that). You'll spend more time figuring out things specific to iOS (cocoa framework, Xcode) than you will about Swift.

All the other answers I've read so far have been good, but do not explicitly mention a key factor that has helped me learn so much.

Do your damndest to find a person more experienced with you in the language that can offer a code review after you create a mini-project or otherwise contributed to a codebase. I've learned alot on my own but having an objective person who understands the language better & can point out things like 'that thing you did in 3 lines of code can be done in 1 with this syntax in this language' has been invaluable to me.

Tap your professional network if you've got one, find a way to get this as part of your learning. I doubt you'll regret it.

First thing I do is look up that language on stackoverflow. There is an info tab which is generally filled out with a ton of resources for that language, for example: https://stackoverflow.com/tags/go/info

Then I pick a simple project that will teach me both the basics and use whatever it is I'm interested in with that particular language.

Additionally, I start a new repo with code snippets. When I need to learn something I write a simple program with an example of it and maybe some variations. So I might have a file named equal.rb and compare equality with ==, eq, nils, "", etc... This helps me learn a specific aspect and later becomes my reference when I say "I know I did this before", it's a lot easier to find in my repo than find a location in a book and remember.

start working on some problem / task that's interesting to you. Every time you encounter some aspect of the language you don't understand, or aren't confident about, write a unit test for it that tests how you _think_ it behaves. If you're right, it will pass. if wrong it will fail. modify test until it passes. Then SAVE these tests as reference for how these parts of the language work while you're learning.

Head first.

Open Xcode and start dropping controls over the initial form, then run it, close it and make buttons click, textfields do some calcs and tables show some records. If you can do that there is nothing you won't be able to do.

I do a tutorial of the language I want to learn, but often I find it is not enough. So, I just browse open-source projects (usually GitHub), check their programming style, learn new tricks (some are not usually mentioned in tutorials) and only then I contribute to the project. Most of the times I get code review for free. This practice has also other positive effects.

I use the new language to write a non-trivial program (several thousands of lines) that I've written before several times, knowing all the algorithmic and design pitfalls so I can be certain that I need to learn the language's own tricks only.

I write a simple address book type app. Basically covers all CRUD operations and allows me to create a nice ui on top. Also handy to have demonstratable code to show your boss or a potential new gig.

I learned Go mostly by doing the Whispering Gophers tutorial over a couple small meetups: https://github.com/schmichael/whispering-gophers

There are lots of aspects of that learning experience that I think are worth repeating:

- social: we all had to figure out GOPATH together!

- playful: it's clearly a toy which means you have the freedom to explore, goof off, stretch yourself, and be creative

- comprehensive: it actually covered a ton of pertinent Go knowledge: goroutine, networking, interfaces, chans, select, etc

IMHO, Hours reading a programming book > hours practicing, in term if knowledge gains.

Type in every line of code from whatever book (dont just read it)

I do simple exercises by myself (pastebin clone, fib, file manipulation etc.)

I try to avoid example code snippets, since I want to figure it out myself.

Oftentimes when reading those examples everything seems to make sense, but when I'm faced with repeating what was shown I get stuck.

So now I avoid them completely and try to figure if out myself.

I force myself to read a book about it, from cover to cover; then I start using it. That gives me a helicopter survey of what the language looks like and its main ideas.

Of course I forget all the details, that's what books are for. It does seems more effective than just trying to map what I know from other languages into the new one.

I don't seek to learn new languages - they sort of come by when I have a specific problem that I want to solve.

This where I write a few paragraphs about the various languages I learned, realize none of you people have time for reading this and delete it in favor of getting straight to the point:

Not having enough problems(challenges) to solve is usually a major hurdle. Ask yourself why do you want to learn this specific language? Does it solve a specific problem you have? If so, try to solve that problem using this language.

Recent example: I wanted to process audio in realtime and my default approach(JavaScript) just didn't cut it. I stumbled upon Rust and it proved to be a great language for such applications.