Learning Programming Languages

Most programmers are Self Taught to a large degree. One thing programmers have to teach themselves are programming languages. What are the best methods for coming up to speed with an unfamiliar language quickly?

(This page lists general tips for any programming language; click the title of this page for a list of specific tips for learning specific programming languages.)

Syntax and Semantics

One of the first things to learn is the syntax of the language and the semantics of its constructs. This can generally be done just in a few hours, except for very complex languages.

Particularly note any subtle differences between the new language and languages you currently know.

Inexperienced programmers think this is the largest and most important step in learning a new language, seasoned programmers know it is the smallest.

Standard Libraries, Classes, Modules, Units, ...

Despite what some programming-language purists think, learning the standard libraries for a language is a fundamental part of learning the language. Just knowing the syntax and semantics is not enough - it is important to understand how applications are typically developed with that language.

How do you open files and read/write them?

How do you open network connections?

What's the easiest way to do interprocess communication between programs written in this language? And what's the easiest way to do IPC with processes written in other languages?

How do you create GUI applications?

How do you connect to a database?

How do you create threads or subprocesses?

Can you link to code written in another language (statically or dynamically)?

Can the same code and libraries be used with other operating systems?

Other Available Libraries

Besides the standard libraries, find out what other libraries are available and commonly used with this programming language.

Find out if there are bindings available for this language and a library with which you are already familiar (for example, Tk (see Tcl Tk), Fl Tk, or Wx Widgets). Also check out whether Simplified Wrapper And Interface Generator or similar tools support this language.

Read Lots of Examples

Learn the common idioms of the language.

If possible, read code and books written by the inventor(s) of the language. That gives insight into why the language is designed the way it is.

Type in the examples, and get them working. This helps you internalize the syntax differences from more comfortable languages. You also get comfortable with the language's development environment.

Port a Program from Another Language

Take a program that you wrote in another language, and that you understand well, and try to port it to the new language.

Don't worry about writing code idiomatically in the new language; just get it ported. Once the code is working, though, let someone more familiar with the new language review your code and suggest other ways of doing things.

Do a Small Project

As soon as you think you "get it", write a small, but useful program in the new language. Having a real-world goal helps one to focus on what's important, and also teaches one how to search through the documentation to find the information you need. It also helps determine what else you need to learn.

The program should be small - writable in a few hours - but should include some non-trivial aspect: GUI, database, parsing text, network protocols, printing, etc. To put it another way, don't just develop a Hello World program; do something that will test your understanding of how to use the language to express the solution to a "problem".

Accumulate a collection of such goals to apply the new language to (see Programming Chrestomathy for a few starters). Each one illuminates the language from a different angle. Seeing the same program - writing the same program - in different languages brings commonalities and differences between them into relief; different programs bring out different contrasts. (Meanwhile, your understanding of the original goal is deepening as each program is a reflection of that from different angles - and that deeper understanding can then feed back into how you write the programs.)

If the language is geared toward a particular type of problem (examples: Perl Language for text manipulation, Visual Basic for GUI development, Prolog Language for rules-based analysis), your first project should focus on that type of problem. Don't try to use the language for a problem that is a bad fit: that will only lead to frustration and a lack of understanding of what is good about the language. Pick The Right Job For The Tool.

Try to write the program using the fundamental features and common idioms of the programming language you are trying to learn. You can write C-like code in almost any language, and you can write Smalltalk-like code in almost any language. But don't.

You'll probably make a lot of mistakes, but that's good - the faster you make mistakes, the faster you'll learn.

Build the Test Code

One of the lowest risk ways to get your feet wet is to build test code for the project. If other team members know the programming language, let them write the production code and you can write the test code. If you are working together on this, it is a great way to learn new concepts and then apply them.

I think the above only applies to language in a paradigm you're already familiar with. I can't imagine a life C/C++ programmer picking up the semantics of Ml Language in a few hours. -- Noel Welsh

Maybe true, but I don't think "paradigms" really matter that much. One can write object-oriented or functional programs in C++, and one can write procedural code in ML or Scheme. But it is certainly true that the more programming languages one knows, the easier it is to pick up a new one. -- Kris Johnson

Don't underestimate the effects of alien paradigms. I've always been interested in new programming languages and, way back when I was an eager young teenager (who knew Basic, Pascal, Fortran, APL, and Z80) I came across Simula67. I tried reading the (rather terse) manual but at a certain page I got a headache. I tried several times with similar results then eventually gave up. Years later, when I saw an article on Smalltalk, I suddenly understood what Simula was on about all those years ago, and realized that my headaches had been a physical response to not understanding the new (and poorly explained) object paradigm. At the time I didn't know I didn't understand it... I just got a physical reaction. -- Peter Hill

Obligatory quote: A language that doesn't affect the way you think about programming, is not worth knowing. - Alan Perlis

Another amusing quote I came across recently:

''You shouldn't give up on learning something important if it takes more than a few tries. Becoming a decent Lisper takes more than a few sessions. It's similar to becoming really good at intercourse: you need more than a week plus access to at least one other person who knows what they're doing.'' - anon

I was teaching myself Cee Plus Plus a while back and I managed to ramp up with it amazingly quickly by reading everything I could get my hands on and writing a lot of code to feel the language out. I got to the point where I was very comfortable with the language in about 8 months. If you think that's a long time (especially if you think you know Cee Plus Plus) then you don't know Cee Plus Plus.

Of course, Now I'm reading Andrei Alexandrescu's book Modern Cee Plus Plus Design and am realizing than for all that I was doing some really cool stuff with the language, I really was only scratching the surface. I'm trying to get back into it now, as I really do prefer how close it is to the system versus Java and how object oriented it is versus Cee Language. -- Bruce Ide

How about Read Then Write? The best book I've read with this philosophy is Refactoring Improving The Design Of Existing Code.

Read a lot of examples to see how the language works.

Learn the proper idioms.

Check out the standard libraries.

Far too many books I've read use these 1/2 page toy programs that demonstrate a feature. If I never see a case statement that returns "foo" "bar" or "baz" again, it will be too soon...

I knew C++ syntax and semantics and used it to write programs for five years before I learned what object-oriented programming was really about (and that only occurred due to working in a bunch of other OO and non-OO languages). Then again, I'm pretty sure that I still don't understand OO as much as I think I do. ;-)

On another occasion, I was working on a large C++ module when I suddenly realized that what I needed was not a huge, complex C++ module, but a simple C++ module with a slightly tweaked functional language interpreter embedded into it. I didn't know what a functional language was at the time, so I ended up finishing the module in a few hours, and then spending three months filling the gaps in my knowledge of the theory involved. -- Zygo Blaxell

It occurs to me that it is pretty easy to learn to write in a certain language. Learning to think in that language, however, can be much harder. -- Simon Heath

For tips on learning specific programming languages, see Iwanna Learn.