
Ask HN: How do you "learn" a new programming language? - f4stjack
Greetings,<p>After spending several days while meddling with ExtJS 4 to grok it, a question occured to me:<p>What does HN users do when they start to learn a new computer language or framework? Do you "memorize" the reference manual, or what?<p>Thanks!
======
fogus
I have a set of pet projects that I tend to recreate:
<http://blog.fogus.me/2009/05/29/pet-projects/>

~~~
hxa7241
Yes, I do a translation of MiniLight <http://www.hxa.name/minilight/> .

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.

~~~
StavrosK
I love how the fastest one is Python with ShedSkin...

------
to3m
What to do (well, what I do anyway):

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.

------
benjaminwootton
Try to learn the topic top down rather than bottom up.

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.

------
raju
Wow! Lots of great suggestions here. I especially liked @fogus' suggestion on
maintaining a list of pet projects that you work out in each language. This
way, you don't struggle with the domain any more - you just have to fight one
learning curve.

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.

------
Someone
For a language, once it has grabbed my interest, I read the reference manual
or something fairly close to it (Stroustrop instead of the ANSI C++ spec)

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.

------
ayers
I use that language/framework to create something. For me I don't retain
information from reading a reference manual cover to cover. I need to actively
work with the language/framework in combination with the reference manual
which helps give it a context. I find this helps me retain and understand the
things I am trying to learn.

------
ashazar
Hello,

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

------
rohitarondekar
The usual suggestions ― books, tutorials, screencasts, pairing w/programmers,
university courses etc.

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>

------
FranklinChen
I'm early in the stages of learning Clojure, so here's what I've done so far
and what I plan to continue doing.

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

------
chegra
1\. Have something you need to code.

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

------
lightblade
What I've found to be the most efficient way of learning new programming
languages..is not by using it. While is it true that you need to use it to
gain mastery. It is best to learn new language as simply as a programming
language. That means studying its features rather than syntax and grammar. Is
the language object oriented, functional,or multi paradigm? The point being
that syntax and grammar changes all the time from languages to languages, but
programming paradigm rarely changes. Truly grasping the idea of a programming
paradigm will make you learn new language a lot faster..and new programming
languages emerge almost every year.

------
samarudge
Open source code. Tutorials, screencasts, books, they teach you /how/ to code,
they don't actually get you to do it. You can get to the end of a book and
have memorized all the code samples but still be without a flying fuck how to
write a program or fix a problem.

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.

------
kokey
I usually start with a small project, sometimes something I've implemented
before. The first thing I do is start from a Hello World example, and then
expand that with features to get to the program I want. I do these features
from examples, and I manually type the examples over. This way I get my
fingers and eyes used to the syntax quickly. Once this abomination of a
program that consists of bad structure and examples from the web is done, I
track down some proper examples of complete programs to see how things should
be done and investigate the differences between that and the approach I've
picked up so far.

------
dgulledge
I read just enough about it that I can get a "Hello, World" program written
and running. I then try a few things to modify that program to learn more
about the language. In particular, I'll often try breaking it in several
different ways. If I know what I broke, then I can learn how to interpret
error messages.

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.

------
dpkendal
Start writing programs in it.

~~~
freehunter
It's hard to read a book in German if you don't know the vocabulary.

------
mischa_u
I subscribe to podcasts and watch a couple video presentations.

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.

------
osa1
I found writing some complex data structures is great way to learn basics of
language. And then you can iterate and improve your data structure to make the
code more idiomatic and/or faster.

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.

------
platzhirsch
I find this question especially interesting in terms of, that it is not the
first language you learn. You don't want to spend time on a book, that is
reintroducing common concept to you, this is just boring. I have, however,
still the desire to buy a book for this purpose and read it from beginning to
end including all exercises, but thinking rational about this, that is utter
nonsense.

------
peteretep
I used to just start poking around in it. Now I combine putting the reference
manual in to Anki (although any Spaced Learning System should work) while I do
it. This way you remember and learn all the edge cases, so they're there right
in your head as you're learning to flow program it.

~~~
f4stjack
Never heard of Anki(<http://ankisrs.net/>) before. Thanks for the
recommendation.

------
mgallivan
This is in a similar vein to most of the answers...

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.

------
agentultra
I start by trying to build a program I already know how to make. Something
simple like a number-guessing game.

If I like the first couple of experiences I'll pick up a reference manual and
try something a little harder.

------
jpitz
Project Eueler, mentioned here many times, is a great set of problems to use
while exploring a new language.

<http://projecteuler.net/>

~~~
f4stjack
My first thought was "Hmm it may be useful for learning nongui languages, but
what would happen if I try to learn ExtJs with it..." Then it occured to me,
you have to put a gui to present results.

Thanks!

------
zorkerman
I usually just redo a set of projecteuler.net problems, until I get enough
context of the language to feel like I don't have to look up every single
language construct.

------
tzs
My preferred method is to find the equivalent of K&R for that language, read
it, and then start trying to program, supplemented with internet searches if I
run into something that it turns out I didn't understand, or to find neat
libraries.

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.

~~~
f4stjack
K&R?

~~~
Pran
<http://en.wikipedia.org/wiki/The_C_Programming_Language>

------
gaius
There are a bunch of things you need to be able to do in _any_ programming
language for it to be useful for real work, e.g. get parameters from a command
line, connect to a database, read and parse a file on disk, send a message to
syslog, etc etc. I start by implementing a trivial program that does these
things, and in the process pick up the syntax, and overview of the libraries,
and end up with a framework on which to actually build my first real program
in that language on.

