Cremains the most popular embedded programming language, and it has been number one for years. Still, your toolkit should include a bit more, especially when dealing with trends like the new and improved Internet plus heterogeneous and multicore systems. Some options in that toolkit might be scripting languages, parallel programming, and graphical programming.
Scripting languages started out on PCs and servers, but they're equally applicable to embedded systems (see "Using The Right Tools: Embedded Scripting And Other Ideas"). This is especially true for 32-bit systems that have the storage to handle the overhead of a scripting system.
Furthermore, scripting languages have been used on the server side in large enterprise applications. These applications often are spread across dozens of servers. But each instance tends to be relatively isolated, so they can be spread arbitrarily across the servers.
Taking advantage of an ever-growing number of cores will require programmers to take a larger role in coding parallel algorithms so cores can cooperate. Current programming languages can use frameworks like the message passing interface (MPI), but this approach requires significant effort at design time. The approach scales, but not necessarily as well as one would like if the system design isn't done right. This is one reason for the growing interest in parallel programming languages (see "Parallel Programming And Multicore Environments,").
The main difference between enhanced single-threaded languages like C with MPI and parallel programming research is that parallel programming research normally assumes implicit parallel execution. It's a bit premature to add languages in this area to your toolkit, but it's worth tracking to see when they will prove useful.
Graphical programming languages and environments like National Instruments' LabVIEW, MatLab's Simulink, and the Object Management Group's UML (unified modeling language) tend to extend programming toward novices and experts. Novices benefit from the encapsulation that hides complexity, while experts get a way to present sophisticated algorithms in a fashion that's meaningful to everyone else. Anyone who has used IAR Systems' visualState knows how much easier it is to look at graphical state diagrams versus inline C code (see "Developing ARMs").
These graphical environments have seen steady improvements targeting text-based programmers (see "UML And C No Longer Oil And Water,"). Developers may still prefer text or graphical programming, but the all-or-nothing approach appears to be gone.
Many developers wait until something new is thrust upon them. Developers who are more proactive will seek out the new so they can be prepared when it becomes a requirement or specify it when it is advantageous.