Is that down at the machine code level (a factor of the compiler/linkage editor) or at the source code level? Does it matter if the language is fully compiled, p-code or interpretative?

C (all variants) can have an 'efficient' characters used in source versus effect in code ratio, but (IMHO) that involved code that is hard to maintain. Ditto for Perl. Want to lob vast swathes of data about - try COBOL. Want to do intense maths, look at FORTRAN. APL can do a lot with very little and might be my suggestion.

The moon on the one hand, the dawn on the other:
The moon is my sister, the dawn is my brother.
The moon on my left and the dawn on my right.
My brother, good morning: my sister, good night.
-- Hilaire Belloc

The most efficient code in terms of processing performance is rarely the most efficient code in terms of bottom line cost. My pokey MS Access hacks sure ain't elegant but they sure are a lot cheaper than going through the whole ordeal of putting together a BRD, ERD, approvals, team meeting, and six months of development involving a team of developers. And you can often have the result today.

If you're counting characters, though, I'm not sure what the objective really is. Perl would probably be the winner there for the concise but cryptic "I can do THAT in ONE line of code" approach that many perl coders seem to find optimal.

This generates all prime numbers from 1 to R. I guess an APL dialect called J might also be up there.

I remember an ex-colleague called Will showing me an APL 'program' that picked out a record from a VSAM KSDS and displayed sections of the data. It was, if memory serves, a single line of code.

The moon on the one hand, the dawn on the other:
The moon is my sister, the dawn is my brother.
The moon on my left and the dawn on my right.
My brother, good morning: my sister, good night.
-- Hilaire Belloc

> For uni I have to do a project on what is the most efficient programming language.
Sure, what is your measure of "efficient"?
- the quickest to write
- the easiest to debug (or maintain)
- the smallest number of source code characters
- the smallest executable file size
- the smallest run-time memory footprint
- the fastest program run-time
- the time it takes to find a competent programmer of 'x' to do the job (*).
- how easy it is to find a compiler/interpreter for language 'x' on machine 'y'.

If you focus too hard on one specific measure of efficiency, then a lot of other useful measurements in the whole picture go out of the window.

So for instance, I could say "good luck trying to find a programmer to maintain your cryptic APL program to make it run on a smartphone".

(*) for example, I just searched monster.co.uk for APL and got 3 hits, and all of those were for Python, with APL as a "nice to have". Java on the other hand was a solid 1000+ hits.