:: Re: [Dng] [OT] Debian problems with…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Didier Kryn
Date:  
À: dng
Sujet: Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds

Le 04/03/2015 00:36, T.J. Duchene a écrit :
> On Tue, 03 Mar 2015 12:46:17 +0100
> Didier Kryn <kryn@???> wrote:
>
>> 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.

>>
> Fair enough. If you need that level of abstraction to get the job
> done, so be it. It's at least a better reason that most of the others
> that I have heard. I would comment that levels of abstraction can be
> achieved in any language, and that C is just as good any other at doing
> so.
>
> You use abstracted libraries everyday.
>
> Although I would have to disagree that C is not tied to the hardware.
> That is the whole point of C. That is why C is used over assembly and
> why C is considered a universal language. It's usually the first one
> ported to any processor.
>
> Saying it is hardware dependent doesn't make sense when C, and the
> Linux kernel written in C are used on so many different forms of
> hardware.
>

     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.


>> I had
>> experiences of big programs in C and my experience is that debugging
>> is long (and probably never ended) and evolution is a nightmare.
> That can be true, but it is also true of any language, or of project of
> substantial size: say 2,000,000+ lines of code. It really depends on
> how well it was designed and documented.
>
> It can be discussed

     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.


>> wether the choice makes sense, but I don't see even why C should
>> always be considered.
>>
>>
> Efficiency and guaranteed portability, Diedler. You can't say the same
> of Python, Perl, etc - because in order to use them, you have to
> compile them from C first.

     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