On Tue, 03 Mar 2015 12:46:17 +0100
Didier Kryn <k...@in2p3.fr> 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.


> 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
> 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.

Cheers!
t.j.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to