AVR Freaks

To be honest while it is C++ apart from member functions and over-loading they don't really use any ++ features and it might just as well be plain C. So you have learnt C, well done! 

So...the arduino language is the languange used in the .hex files that we burn in the AVRs???

Err no.

CPUs just fetch number patterns and some bits set in some of those numbers tell it to perform an operation like an add, shift or jump.

That sequence of numbers (opcodes) is encoded into ASCII using Intel Hex format in .hex file just because it makes the numbers easier to see, study and email (which was the original reason for these ASCII formats that hold binary number values). But hex is still just a block of number patterns for the CPU. In no way is it a "language".

The first hint of a "language" is one step above the number patterns. The silicon vendor (Atmel in this case) gave each of the number patterns a helpful, human readable name to make it easier for humans to understand. So the number 0x0C73 which tells the CPU to add the contents of R7 and R3 and put the result in R7 is given the "name" ADD R7,R3. Now that is is a language. It's assembler. But in the .hex file it's just 730C and nothing more.

A level above this is C where you may have written:

a = a + b;

and the compiler turned this into something like:

LD R7, Y+1
LD R3, Y+2
ADD R7, R3

and as well as the opcodes for the two LD's the ADD here is what generated the 0x0C73. Again C is a "language" - a set of words that you the human understand that let you put down in words what you'd like to achieve (in this case add 'b' onto 'a'). Arduino or C++ or C then just take these words and structures in that well defined language and use them to generate another language: Asm. Then the assembler reads that language and just converts it into a load of 16 bit numbers and that's what is in the .hex file and ultimately in the flash of the AVR and fetched by its CPU and interpreted as nothing more than bit patterns turning on particular transistor paths. (in this case eight "full adder"s that add the 8 bits in both 'a' and 'b').

From a hex file you cannot recognize the used language and it is not important at all.

Actually you kind of can. If you take a .hex file and run it through a disassembler then if you find it always using the same registers (and order) to pass values to functions then, in those functions, creating space on a stack somewhere for local variables it's a pretty fair bet you are looking at code that originally came from a C compiler.

When you first look at disassembled C code your first thought is often "why on earth are they doing things like that?".