
Ask HN: What is your best way to learn a new programming language? - deadcoder0904
I know the good old answer, practice.<p>But are there any tricks that work for you while learning a New Language or you just get better.<p>I want to learn Swift as my new language so how do I approach it.<p>I know a lot of different languages but they have basically same syntax (C, C++, Java, JavaScript) but it takes me a lot of time to get a good grip of it and I am not sure if experienced developers feel the same or do they learn it faster.<p>So what&#x27;s the best way to learn it and maybe the fastest?
======
scarface74
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.

~~~
deadcoder0904
Point 2 is spot on. I sometimes make projects that nobody will ever use, not
even me. I heard this advice from someone. Make lots of throwaway projects to
get familiar with the technology. But I took it too far. I only used it to
make throwaway projects. Now will make something that is useful. Thanks for
all the insights. Very helpful.

------
jupiter90000
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.

~~~
philfrasty
Do you know of any website doing this? Similar to language tandems where each
person brings something to the table.

~~~
andremendes
Yes, [http://exercism.io/](http://exercism.io/)

------
LanceH
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](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.

------
jfaucett
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.

~~~
deadcoder0904
The problem is it gets really irritating building the same thing again & again
in multiple different languages. The only application I have repeated is a
Todo App. But nice advice, I will apply it while learning Swift.

------
bane
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.

------
dvogel
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.

~~~
jenscow
Yes, exactly what I do.

I found that using the new language as though it's the familiar one makes you
quickly understand the limitations. As you try to bend the new language into
supporting your own familiarisation, you accidentally learn the lower level
details.

------
schmichael
I learned Go mostly by doing the Whispering Gophers tutorial over a couple
small meetups: [https://github.com/schmichael/whispering-
gophers](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

------
elorm
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.

~~~
deadcoder0904
I make this mistake a lot. When learning new language, I think just learning
syntax is enough. I had to forget PHP to work with Node, as Node is
asynchronous & when I was working with PHP it was synchronous. Just couldn't
get my head around async code. Very helpful insights.

------
AnIdiotOnTheNet
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.

------
feduzi
Opinionated steps:

0\. Do not know a language X.

1\. Want to learn a language X.

2\. Leave your previous experience behind. E.g. know C, forget about it while
learning a new language.

3\. Read official docs.

4\. Follow the language rules (as much as possible).

5\. Analyse language parts (e.g. concurrency, error handling, etc).

6\. Synthesize the parts. See how parts combine (e.g. error handling in
concurrent code).

7\. Bring back your previous experience (e.g. see how different languages
solve problems).

The main point is to know "what tools present and what can be done with
those", rather than "what is felt about tools present and why the world
sucks".

PS:

A small set of observations:

\- "disliking" parts of a new language while learning returns you back to the
step 0.

\- steps 5, 6 and 7 are almost never ending (especially in languages that
grow).

\- step 7 requires discipline. It is needed not to "pick the best language",
but to understand various ways of solving a problem across different languages
(do not forget to identify a problem).

------
Tade0
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.

------
axaxs
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.

------
tastyham
I usually start by reading either the docs (if they are good quality) or a
book (if the official docs aren't great) and then I code something trivial
after that.

If I'm using it for work I will likely be reading and trying to understand co-
workers pull requests, and then progressively more complicated PRs of my own.

------
upstill
I can't read anything and have it stick unless I use it. But the hazard of
doing a project is that you'll just recycle skills and strategies from earlier
languages, which inhibits your openness to what's distinctive about the new
environment.

The only approach that works for me is dialectic: go back and forth between
absorbing raw information, then using it hands-on on a genuine problem.
Learning moves you forward, and using it locks you in and makes you a dry
sponge for absorbing further material. The trick is to notice when you're
trying to fit your old ways into the new box, and stay alert for opportunities
to change your way of thinking.

...or maybe I'm just saying this because I'm working on learning Clojure after
decades of procedural programming.

------
baby_wipe
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.

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

~~~
deadcoder0904
This is exactly what I do now minus reading the docs. I never read the
original docs for anything except React. I don't know what made me do that but
I remember I tried reading it but it was too big & I felt intimidated.
Although, the docs nowadays are good enough & not scary like Vue, React,
etc...

I guess I should start reading the docs because sometimes the answer I find
Googling is already present in the docs :)

~~~
sparkie
I find reading the docs is the best way to truly understand a language.
Reading other tutorials, books or starter manuals kind of gives you a tour of
the most popular parts of the language and you have to piece them together
yourself (although a good book may explain it in a more friendly way).

Perhaps it comes with experience. My first few languages were learned ad-hoc
like most people learn. Only after experience with a few languages did I start
reading the manuals and getting an even better understanding of them. You
learn a lot even when you previously thought you were already fluent with a
particular language.

I find it really helps to write a parser for the language (Assuming the
language can be parsed with a LL/LALR Grammar or PEG). It doesn't need to be a
robust parser which handles all errors, but just a trivial one which can help
you to understand all of the edge-cases in the syntax. A parser you wrote
yourself makes a good reference. Depending on the complexity of the language
this can take a few hours to a few days to write.

Once you have mastered the syntax, begin to tackle the standard/common
libraries bit by bit. Try to write small but useful applications to utilize
particular parts of libraries. Name them well so they're easy to refer to
again later, so when you come to need a particular library feature you can
look up how you done it last time. (Although you'll usually look at these and
be like "What the hell was I thinking back then?")

So if I were to be learning Swift, I'd grab the ePub from here:
[https://swift.org/documentation/#the-swift-programming-
langu...](https://swift.org/documentation/#the-swift-programming-language) and
skip directly to page 917 which lists the language's context-free grammar.
This is essentially a 42 page cheatsheet for the entire language syntax (could
probably be condensed to about 15 pages if split into two columns and
whitespace removed). This epub is a great example of well-written
documentation. It's broken into groups of production rules with good cohesion,
and every terminal and non-terminal symbol in the grammar is hyperlinked to
the part of the document which describes it in more detail.

I'd read through the grammar and perhaps even rewrite it side-by-side as I'm
going through it. (There are some good tools for writing and testing grammars
interactively, which I would definitely make use of). I'd guess since the
language borrows from C#, Java, Haskell et al, which I'm already familiar
with, that I'll be able to understand the majority of it without looking up
details - but when i do encounter something I'm not sure of it's just a click
away.

------
masukomi
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.

------
antonio-ramadas
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.

------
dsw108
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-...](https://www.theguardian.com/science/2011/may/15/quantum-man-richard-
feynman-review) '"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, think about
it, refactor it, can also be helpful. However do this _after_ you have the
skill. The standard advice in Zen practice is the same: "practice first, study
later".

If you think that this cannot possibly work, then think of how you learned to
speak your native language; did someone explain the rules of the grammar to
you as a baby, or did you just rote imitate it? Non-native speakers of English
have asked me why a feature of English is the way that it is or what the rule
is for a certain situation in English. I tell them I have no idea.

Our school system lies to you completely. LEARNING A SKILL IS NOT ABOUT THE
CONCEPTS, IT IS ABOUT ROTE MINDLESS IMITATION UNTIL YOUR BRAIN HAS
INTERNALIZED THE IDIOMS. Your brain _cannot_ memorize the massive amount of
detail in all of the examples, so it _must_ abstract them into idioms; once it
has done that, you simply have the skill and you do not even know how you do
it yourself. How exactly do you approach a door and open it? If you think you
know, then please explain it to the teams of people at places like MIT who are
trying to build a robot that can do that, because it is very complex. You do
it and you do not even know how. But you can do it.

~~~
scarface74
_LEARNING A SKILL IS NOT ABOUT THE CONCEPTS, IT IS ABOUT ROTE MINDLESS
IMITATION UNTIL YOUR BRAIN HAS INTERNALIZED THE IDIOMS._

Technology and languages change. They have definitely changed a lot since my
first combination of hobby AppleSoft Basic, 65C02 assembly language programs
in the mid 80s. But concepts remain. I've gotten to the point in my career
where most interviews don't focus on technical minutae of the language I code
in. They focus on high level architectural concepts, best practices, and
leadership skills (I'm still a hands on coder but these days I'm usually
either officially by title or day to day in reality an architect).

In reality, all of the popular languages in the industry are "C like". I can
watch a video while I'm working out to get an overview of the language and
then just start coding and know what I don't know.

------
phugoid
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.

------
zython
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.

------
yason
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.

------
Entangled
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.

------
evo_9
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.

------
weppekroka
A good way is to take a mooc (coursera, edx, udacity,...) - you get video
lessons, slides, programming exercises, everything to cover the basics

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

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

------
hguhghuff
Watch YouTube videos

~~~
deadcoder0904
The problem is you don't know what to watch. Earlier there was a problem when
there was no YouTube & now it is problem because there are like tons of videos
on a same thing & you can't be sure what to watch. Popularity is sometimes a
flawed metric too. I have watched few awesome videos but the views for that
were very low & I have watched some videos in which the view count is high but
the content is mediocre.

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

