Musical programming languages are a strange breed of flexibility and usability in the computer music domain. There's actually a long history of musical programming languages (in the context of programming in general) that recently has been seeing a surge of popularity among the arts community. C++, we all would agree bears very little usage bias, while CSound is obviously not a good programming language to check your e-mail with. C++ may be perfectly capable of creating the same results as a CSound program, but the initial knowledge level required to do so is a vastly different range.
The major (read most-popular) open-source audio programming languages are PD (pure data), CSound, SuperCollider, and ChucK. Each of these languages have their own strengths and weaknesses and some are easier to learn than others. For most musicians PD will be the most appealing with the smoothest learning curve as it is the only graphical language of the four. ChucK and SuperCollider are much closer to "real" programming languages in their syntax. CSound is the oldest of these four, with roots from back when you'd write a computer score, set it to compile, and come back three days later to hear your audio file. Because of this, CSound is a very powerful synthesis engine that was written with computational resources in mind.
Many musicians will never need to learn a music programming language, but recently more and more artists are turning to programming languages to give the extra flexibility their project requires. A few possible applications include; using a wii controller to adjust a synthesizer's settings; building your own ultimate modular synthesizer; altering a live signal with a complex chain of adjustments - each of which are manipulated on the fly; trigger effects on/off based on the frequency of the input signal; building audio effects not otherwise available; generating algorithmic melodies, rhythms, etc..; extending the functionality of your favourite program; creating your own custom-designed software; or working with homemade hardware controllers (linux hackers get excited about this stuff).
These are all good reasons for using audio programming languages, but there are some common downfalls to creating these custom audio apps/plugins/tools. The first and most obvious is that the time spent coding the tools quite often overshadows the usefulness of the resulting tool. Many gear-heads fall into this trap when they first learn to program in PD, as they realize that nearly anything is possible so they try to do everything. This could be argued to be comparable to the amount of time/money gear-heads spend on buying hardware in comparison to their actual musical output. The second is that most musicians aren't computer programmers. This may sound like an obvious statement, but it's also a serious problem in music programming languages. The software that musicians develop is more often than not: VERY buggy, inefficient, half-finished, unportable, not documented (not even comments in the code), and essentially broken in design. Because of this, nearly all of the software musicians write becomes a one-off, non-distributed tool that even the creator soon refuses to use (often after the first performance) - in the software world these are called "dead projects" and are seen as massive failures. Even the software some of my university professors - who get grants to write them - create, will be prone to these pitfalls, and it comes down to musicians thinking like musicians rather than programmers; though some musicians will claim they make more musical tools that way. There are exceptions to these faults, but they're unfortunately exceptions and not the norm.
Now that you're aware of these pitfalls, you're one step ahead of the average musical programmer, and you can avoid them in your own code; right? Okay, the I guess I can teach you a bit of programming now.
PD is the easiest for a beginner to stomach because of both it's visual element and it's patch-cord based interface that resembles musical hardware routing. I wrote a quick beginner's tutorial for PD a while back that has been incorporated into the Ubuntu Community Documentation here: https://help.ubuntu.com/community/HowToPureDataIntroduction and I don't want to repeat myself.
#####********* IF YOU KNOW NOTHING ABOUT PD, STOP NOW AND GO READ THAT LINK ********######
At the end of that tutorial I had promised some further examples, so I guess I should deliver. The first thing I'll touch on is the ability to create an abstraction. This is thoroughly explained in the PD documentation so if you're lost after this, go take a read there. Essentially an abstraction allows you to package PD code into a custom named PD object for use in other patches. This feature is invaluable for PD programmers. Without abstractions, code would become a rats nest of patch cords quite fast, and each patch would be a one-off code snippet - preventing any real software development. Abstractions allow the programmer to clean up the code, easily re-use code snippets, and speed up their coding process.
By encasing a mundane (yet laborious) set of instructions into a single abstraction, anytime those instructions need to be called, it's simple and elegant to create a new object and call the abstraction's name. To create an abstraction simply save your pd patch as examplepatch.pd, then open 'Path...' from the File menu, enter the folder that your abstraction was saved to (you may want to save the settings), then open a new patch and create an object named examplepatch. To see the original code, right click on the new object and select open.
You can send data to and from these abstractions in two different ways. The first is to use "inlet", "inlet~", "outlet", and "outlet~" objects in the abstraction's code. These will allow you to connect patch cords to and from your abstraction. This method is simple and best for beginners. The second method involves the "send", "receive", "throw~", and "catch~" objects. These all take a name for an argument that will point to the send/receive/throw~/catch~ object that's giving/receiving the data. The upside of the send/receive method is its flexibility, whereas the downside is that it allows you to loose track of signal flow quite easily - particularly when multiple signals are going to the same place or vice/versa.
This encapsulation of a code snippet is an essential element of the Object Oriented Programming style. This style is a very prominent code writing method in modern computer programming. I'm not computer scientist, so I won't attempt a definition for you here, but I will tell you that PD is designed to use the OOP style. By coding a snippet such as a soundfile looper, then saving it as an abstraction, you'll be able to reuse that code chunk to make life easier when you go to build your ultimate sampler, and again when you want to incorporate sampling into a custom-built guitar processor. Abstractions can be nested inside one another too, allowing for very complex patches to be organized very efficiently.
I'll end by saying that PD is a wonderful beginner's programming language that can accomplish quite a bit, but it does have its limitations. For a VERY detailed read on PD, I'd recommend Miller Puckette's (the man who wrote PD) new book The Theory and Technique of Electronic Music, available as a free download online. The other three music programming languages that I mentioned at the top of this post should also be explored by those who have a penchant for flexibility and power (my personal favourite is ChucK).