What’s the best language to learn for embedded systems — C, C++, or Python?

Someone just emailed me asking me this question -- I replied as follows, but it would be great to hear what other community members think -- Max
-------------- My response follows ------------
This is a very tricky question because there are lots of different ways of looking at it. C can generate the smallest, fastest programs, but it also allows you to do horrible things. The object oriented aspects of C++ are very powerful, but it takes a lot to "wrap your brain" around it. Python is the easiest to learn, the fastest to write programs in, and the most intuitive -- but the resulting applications will not run as fast as their C equivalents (this may not be a problem depending on what you are trying to do).
In the case of embedded development systems -- there's more support for C/C++ than Python -- but this may or may not be a problem. Take a look at the following column I wrote a while back and see if it helps answer your questions: Python is better than C! (Or is it the other way round?)

As a long time C programmer, I'll admit to having a bias in favor of C. I've also written C++ code for an embedded system. but the low level code was all written in C. Of course I got started writing assembly language so I was delighted to be able to work in C instead.
As you might expect from the names C and C++ are very closely related to the point where most C compilers will accept some C++ syntax.  Since the trend is to more powerful processors and more complex systems, it's wise to have expertise in higher level languages but for now, I think that C or C++ is still the best to learn for embedded systems.

I agree with Elizabeth, I also have a bias toward C but this was not always the case. The problem with C is that it is very easy to write very obscure code, and not document the code.It was because of this that I first started to use an embedded Pascal compiler, Pascal has  very strong type casting and great Function and Procedural abilities and you will probably never have to master pointer use as you do in C.
Having said all the above there are some great Basic compilers for embedded programming especially for AVR chips, which compile to as tight code as C will produce..

I personally think the underlying algorithm one uses to program for embedded applications is most important, not the actual language used (in spite of each one's ups and downs). Thus, the dilemma of programming language preference simply becomes a superficial test of one's aptitude in semiotic analysis.

@justin: "...the underlying algorithm one uses to program for embedded applications is most important, not the actual language used..."That's a very good point!

@Conrad.: "... I first started to use an embedded Pascal compiler..."Me too! I used Assembly and BASIC and Fortran at University -- but my first high-level language in industry was Pascal -- I no longer have any clue whether it supported pointers or not.

While I agree with Justin that the underlying algorithm is most important, if you actually want to be employed as an embedded systems programmer, you really need to know C.In a recent project I was involved in, the algorithm was developed in MatLab then converted to C/C++ to be ported to the embedded platform.I just looked at the curriculum for an Embedded systems degree from Oregon Tech. They start the students off with C++ then introduce C. I think this a good approach since learning C from C++ is more learning what parts you don't use.

@elizabeth: "...They start the students off with C++ then introduce C..." That is an interesting approach -- I'd not heard this one before -- hmmm

My embedded software work has been in assembler and C, almost always for barely-fast-enough processors. My first language was FORTRAN, so in C I tend to use array indexes rather than explicitly doing pointer arithmetic. A question for the group:Say A and B are 32-bit signed integers. What languages allow calculating C=A*B, returning the 64-bit product C? I once had to do this, and it was difficult even in assembler.

It looks like some versions of C (for 32 bit CPUs) have a long long int which is 64 bits.
I strongly suspect that this behavior is very much compiler dependent so I'm not sure how far I'd trust it.

I ended up casting the 32-bit ints to 64-bit ints, doing a 64*64-bit multiply, then returning the 64-bit low half of the 128-bit product, all in assembler on a 64-bit machine.One advantage of assembler for hard-real-time embedded systems, is that the execution speed can be estimated before building hardware, so the hardware can then be built to meet the speed requirement.

@_max_ "I no longer have any clue whether it supported pointers or not." The Pascal compiler I used for AVR  development had a pointer capability.@Elizabeth C++  to C as a learning process seems like a very good idea.

It didn't

"is that the execution speed can be estimated before building hardware"I agree, and I would add "C" to that too. I consider "C" nothing more than a powerful assembly language preprocessor. I find that helps writing efficient C applications for low power embedded systems