Le 04/03/2015 00:36, T.J. Duchene a écrit :
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.
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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
