>> Le 02/03/2015 23:43, T.J. Duchene a écrit :
>>> We just see things differently.  My first question would be: is
>>> there are a justified reason NOT to use C?
>>       There is a very good reason, and I heard it was given by
>> Kernighan and Ritchie: "we assume the programmer knows what (s)he is
>> doing". And there is a second reason: C is very tied to the hardware;
>> it is lacking abstractions.

     T.J., I was probably not clear enough. I dont mean 
architecture-dependant, but assembler-like:

     if ( a=b=c ) ; What does this mean?

     1) let some register (call it Accumulator) be loaded with the value 
from location c;
     2) let store Accumulator at location b;
     3) let store Accumulator at location c;
     4) check if Accumulator is non-zero;

     All this is very different of what the instruction means in 
ordinary language and you better keep it in mind or you will get a mess 
sooner or later.

     ++ and -- should never be used in expressions. They have been 
invented to generate post-increment or pre-increment with primitive 
compilers. GCC is perfectly able to generate them automatically.

     C is so error-prone that GCC has introduced  warnings from the most 
dangerous constructs.

      C is semantic sugar above assembler. I do not want to reduce its 
merit. I have programmed in this language for 34 years.

     A given language may do in one line the equivalent of 5 lines of C, 
in a self-explanatory construction.

     A language apropriate for a given type of problem may have well 
thought semantic constructs which, at the end result in calling the same 
functions as you do in C, but are expressed in the source code in a way 
which is easier to understand for the reader and easier to check by the 
compiler.

     My point is that generating efficient code is not the most 
important issue. The most important things are to prevent and detect 
programming errors and to make the source easy to read. Some people love 
C for just the opposite reason: it is short and cryptic and a single 
typo could change program's behaviour instead of causing an error.

     If you take all languages understood by GCC which produce 
executable binary (not Java bytecode), the performance of the executable 
code will be very close, because the code generation is the easy part 
and is paractically all common. The only difference, and it matters a 
lot, is the front-end, that is the language.

     I do not deny the necessity to have C. One of the greatest merits 
of C is that it brings in all the others :-)

     Also let's not confuse "high level" with "interpreted". Shell 
scripting languages are rather low-level. I don't know perl, but I think 
it is not much "higher" than C.

     Cheers.
                     Didier