I usually do the following. Note that it reflects my personal needs in programming, so YMMV, but in general I think it presents a sound approach. It is all done after you've learned the basics, of course, such as went through a few tutorials or a book.

* Write a program that does a recursive directory traversal doing something with each file. Once without using any considerable library support (only open directory, list directory, etc.), and once trying to find a library to do it (such as the os.walk call in Python)

* Write a small recursive-descent parser for arithmetic expressions, with a regex-based lexer.

* Create a simple GUI with a few buttons and boxes

* Create a small multi-threaded application using producer/consumer or something else.

* Write a simple socket client-server pair and let them talk on localhost. Then rewrite it using a popular library for the language.

* Find out how to create a distributable .exe for Windows in this language

* Find out how to call functions from a C DLL in this language.

Write a compiler of a subset of one of those languages in another of those languages targetting one of the other languages. I guarantee you will learn all 3 deeply.

SimpleRL is an ultra-minimal seed for a roguelike game: https://github.com/nrkn/SimpleRL . It'll make you look into doing an application with an interactive UI somewhat less trivial than what you can do with bare stdin/stdout.

From a game development perspective, it's perhaps a bit too minimal (given that the spec can be implemented with static HTML), but it does serve as a sort of hello world for GUI interaction.

That depends on your background and what you want to use the new language for.

For me, the best way is to solve a few problems from Project Euler and then just dive into whatever I want to use the language for.

http://projecteuler.net/

With all my love for Project Euler, I absolutely hate it when people mention it in relation to useful programming skills. PE is about math more than it's about programming. The programming constructs you need for it are very basic and won't teach you much about the language. They won't teach you how that language works for large modular applications. They won't teach you what useful libraries the language has for networking, GUIs, parsing and so on. They won't teach you how to package applications written in the language for distribution. They won't teach you how the language interoperates with other languages (especially C).

Phew, sorry for the flame. Had to get it off my chest. PE is sometimes a knee-jerk reaction to programming queries, and this is wrong IMHO.

While all that is true, I can't think of any quick toy example that covers all of that. I find that plowing through the first 25 or so PE problems is a great way to get the hang of the basic syntax and style of a language. Once you've gotten the hang of the basic style and syntax you can move on to bigger and more 'real' problems. But starting by trying to build a GUI, call a C library and package your program for distribution before you learn how to create, reverse and iterate of an array seems rather backwards.

You learn the syntax by reading a tutorial/introductory book for a language. This is the first step. After solving 3-4 PE problems you begin to realize you're just reusing the same few constructs over and over again, without learning much new about the language.

How do you ensure that you learn the style specific to a certain language and not just literally translate from a language you already know?

E.g. in Java, you would probably solve problem 1 with a for loop, while you could use a generator expression in Python.

Another reason why reading a tutorial or two (or better, five) is essential as the first step. Just jumping to coding programming exercises won't help much in learning how to write idiomatic code for the language.

I'm not suggesting that coding up solutions to PE problems should be done instead of reading tutorials. I mean how are you going to write code if you have no idea how the language works. However I personally find that I learn very little from simply reading a book about a language, I have to write code in it at the same time to help internalize the concepts I'm reading about. And for that I find PE to be a good first step after hello world.

A simple raytracer is a nice and interesting way to learn the basics of a language. You'll probably learn basic data structures, objects, recursion, file i/o etc.

I found Minilight yesterday. It is both more and less than a ray tracer, being a global illumination renderer. It was created as an exercise to learn new languages. Its creator has implemented it in C, Scheme, Scala, C++, OCaml, Lua, Ruby and Flex 2. Others have implemented it in Python, Java, F#, C#, and Clojure.

http://www.hxa.name/minilight/

Jamis Buck suggests generating mazes.

Here's the full article http://weblog.jamisbuck.org/2010/12/27/maze-generation-recur...

These were a great read. Full recap here:

http://weblog.jamisbuck.org/2011/2/7/maze-generation-algorit...

I'm a web developer, so my sample app is either a blog or a Twitter client. This shows me:

* URL handling

* OAuth

* The HTTP client module the language uses

* The storage model

And other common webby things.

I think the problem with this approach is that it's forcing you relying on a web framework and eventually on libraries.

As an exemple a lot of people know how to make a blog in rails but only a part of them really understand what's a class variable.

I'm not saying it doesn't work, just that you could ending up knowing a framework not a language.

> I'm not saying it doesn't work, just that you could ending up knowing a framework not a language.

I agree I'm blurring the lines a little, but when I talk about liking 'Python' or 'Javascript' I mean not just the syntax, but the libraries, the package managers, and other parts of the surrounding toolset.

There are some languages with great syntax, but small communities and little library support. Checking the whole, bigger picture gives me a feel as to whether it's something I'd like to use in production.

If you are interested in web development, this is the ideal way to learn the language. You won't just learn the language, you'll have immediate practical applications for the language constructs.

Unlike the people you speak of, someone trying to learn the language would stop and learn what a class variable is. This is exactly how I learned Rails and the Ruby language. I just dove in to Rails and went to Ruby references along the way.

I would just write your next proper (non-toy) project in the language you want to learn. That way, you learn the language and you've made something.

There was a similar discussion a year or so in stackoverflow:

http://stackoverflow.com/questions/3247812/toy-projects-for-...

I write "snake" when I learn a new language. (for now, c64 basic, qbasic, borland pascal, C, C++, C++ with OpenGL, Python, Haskell, Javascript). It works.

Amazing. I would love to do that too but first of all I need to know how to write snake in a language I already know.

I will try that out in Python and let you know how it is going :D

Yeah, Snake seems like it should be a canonical Python exercise, given the name.

That would work. You'll have many things straightened out by the time you finish creating the snake. :-)

I'd recommend writing something real. Something simple that is useful to yourself or someone else.

A fresh take on a basic tool.

I wrote a few toy apps to assist me learning Python: automatic forum-posting script, text-overlay app (using PIL), a pinboard.in clone (though this was more an exercise in Django), an RSS serializing/importing module, and a few other odds and ends. I write things that I have a use for, especially something I can show other people to get a laugh (esp true with the text-overlay app.)

I believe Basecamp, and by extension Ruby on Rails, was written by dhh to teach himself Ruby. Not exactly a toy app though.

> Not exactly a toy app though.

It could have started as a generic to-do list. That's how I'd begin.

Doesn't that really depend on the language.

And for me to say

> I have a good feel for the capabilities of the language and largely understand it?

I would need to have built, deployed, maintained, rewrote version 2.0, etc of a production app with actual users. Anything else is "Academic Knowledge".

Generally I make a SpaceWar! clone in said language/library.

Typically when trying to learn a new language, I do the following:

* Go through any of the main tutorials or walkthroughs to get a basic understanding.

* Have a read of the API docs.

* Gain an understanding of concurrency, bounds checking and memory management by writing simple apps to test each.

* Write a program to execute another program

* Write a program to access core system info (e.g. registry etc.)

* Write a program that uses sockets or network connectivity (normally a client and server)

The last few times I wanted to learn a new language/platform that involved a user interface I have written an RPN calculator. I just did this over the weekend to learn iOS and Objective-C.

Making a calculator forces one to learn how to work with the user interface framework. Making a sophisticated calculator forces one to learn more about the language and the math libraries available.

I usually write something I want to write which is not too big. If it is some code you want to see, you'll fight with the language. If it is just training code, you may give up (this is how I wrote my first Lisp raytracer, based on Paul Graham's one in ACL... sadly I lost the source for that and the newer one never got to translucency :/ )

For the initial lessons, I would use the material at http://codingkata.org/ (which unfortunately seems to be down at the moment).

That should provide a good feel for the basic language constructs, and the essentials of the standard library.

Sadly, these types of strategies don't work for me. I have to have an itch I need to scratch before I can really learn a programming language. Eventually when something annoys me enough to write code to deal with it, that's when I deep-dive into the language.

Although my choices have changed over time, my ideas on the matter are the same today as when I blogged about it a couple years ago: http://blog.fogus.me/2009/05/29/pet-projects/

I usually always start by writing an IRC bot. Mainly because I know the IRC protocol really well, but more importantly because it let me feel the language. i.e. How easy is it to use socket? What about parsing strings? Reading/Writing files, etc.

In a system with a GUI (Android, Web Browsers, old school X windows) I often do a variation on pong but instead have a bunch of (round) bouncing balls with a simple Newtonian physics engine.

You can find some suggestions from here ("I wish there was an app for..." on Twitter): http://wappr.com/latest

Write a literal toy app that is filled with small puzzles to help the user learn the same language.

I always try to rewrite Facebook from the ground up. Or DOOM.

a wiki! Mine started as a toy to experiment evented programming with nodejs. A year later it's now 26KLOC (in one big file)... :)

I've been in the same shoes as you and I can tell you most of these suggestions, while good to suggest, are difficult to execute for one simple reason:

Why do you care to learn said language?

When I started learning F#, I tried these traditional suggestions: write some data structures and algorithms, go through Project Euler problems. I probably wrote close to a few hundred lines of F#. You know what ended up happening? I can't remember a lick of F#. How could that have happened?

I had no palpable reason to learn F#. I like writing web applications, and the ones that I do like to write have very little use for concurrency or functional programming (also the reason why I'm having trouble getting motivated to write any Haskell/Erlang).

Compare this with Ruby (Rails). I had an idea for a web app. I work on the .NET stack during the day and I wanted to learn another language. I heard that Python and Ruby were the best ones to pick up, and since they are so similar in terms of end goal, I chose Ruby because it simply intrigued me more. I've written close to a few thousand lines of Ruby and I'm at the point where I could write it ad hoc and make something off the top of my head. So what worked this time around?

The keywords here are "idea" and "intrigue."

The number one thing that will help you learn a new language is to have an idea of something you want to build.

It doesn't have to be a new idea. Maybe you want to try cloning ThreeWords.me. Maybe you want to automate picking stocks (a personal favorite). Whatever it is, you have to have an idea of something you want to build, not only because it helps you define the language you should use (and thus give you a compelling reason to learn X instead of Y), but also because it will give you the intrinsic motivation to retain that knowledge after you've executed on your idea. You'll feel like the language has a purpose in your life, an actual tool you can use from the proverbial programmer's toolbox.

The other piece, as I mentioned, is intrigue. You have to want to learn the language to really get any benefit from it. As I mentioned earlier, it ultimately came down to a gut feeling as to why I chose Ruby/Rails over Python/Django(/Pylons/Web2py). This is so important, because ultimately if you're already trying to learn a language outside of work, you've got an internal motivator that isn't driven by profit or work; it's driven by excitement and fun. So follow through on that promise to yourself to have fun by picking a language that makes coding fun! If Haskell bores you but Erlang gets you going, even if Haskell is considered to be a more hardcore functional language...WHO CARES! You're doing this for fun, NOT with a gun to your head or a job on the line. You need to do what's right for you. I don't think I've ever met an individual who said "I picked the wrong language to learn, I'm dumber than I was before!"

TLDR: You need to have a reason to learn said language(s) by first having something to build. That will help you choose a subset of languages you'll actually want to learn. When filtering down between similar languages, go with your gut and choose the one that excites you the most. You simply can't go wrong, and there's no better way to learn a language faster than by building something you've always wanted to make.