Why C Is Not My Favourite Programming Language

[Jonathan Burd]

(e-mail address removed) wrote:


If you would like a string_t type built into the language,
comp.std.c is where you should be *discussing* this.
Whining like you have will not solve your problems. This
problem may also have been discussed in the past, so search
old posts and gain more understanding about the problems
the standardizing committee faces when adding, removing
or modifying features. Compatibility with the *huge* amount
of source code that has already been written comes to mind
almost instantly. Oh, and here `huge` is really *huge*.
I wish I could stress it more than my news client allows.
You cannot simply wake up some day and say, "Let there be
a better string type" and have a string type appear from nowhere.
God didn't have to be compatible with "Humans Version -1."

C, like any other language, has flaws. This is why new languages
come up almost everyday. If you want "safe" programming, please
look at Java or some other popular language. As Dan Pop himself put,
"C is quirky, flawed, and an enormous success." It couldn't be more
true. C is what it was meant to be.

The fact that you're complaining about the language only shows
that you like C and you would like it to develop into something
you would like it to be. So, why whine? comp.std.c is where you
should go.

Remember, C is a sharp blade in the *right* hands and if you don't
handle the blade properly, you risk the danger of injuring yourself
and others. If you don't like C, choose another language that
suits your taste. Stop complaining about C strings, however.
You can give http://bstring.sourceforge.net/ a look.
Nothing is perfect.

Regards,
Jonathan.

 

[infobahn]

C, like any other language, has flaws. This is why new languages
come up almost everyday. If you want "safe" programming, please
look at Java or some other popular language. As Dan Pop himself put,
"C is quirky, flawed, and an enormous success." It couldn't be more
true. C is what it was meant to be.

Actually, it wasn't The Great Dan Pop who first said that. It was
just some guy called Dennis Ritchie.

"We must do something. This is something. Therefore, we must do this."
- Keith Thompson

Actually, this one was from Jonathan Lynn & Antony Jay, not Keith
Thompson.

It was used in the "Party Games" episode of "Yes Minister".

 

[Jonathan Burd]

Actually, it wasn't The Great Dan Pop who first said that. It was
just some guy called Dennis Ritchie.




Actually, this one was from Jonathan Lynn & Antony Jay, not Keith
Thompson.

It was used in the "Party Games" episode of "Yes Minister".

Actually, I must have been mistaken about the quotes. Actually, thanks
for correcting me.

Regards,
Jonathan.

 

[Keith Thompson]

Off topic; please stop reading now.

Jonathan Burd wrote: [...]

"We must do something. This is something. Therefore, we must do this."
- Keith Thompson

Actually, this one was from Jonathan Lynn & Antony Jay, not Keith
Thompson.

It was used in the "Party Games" episode of "Yes Minister".

Really? I've been using that as my sig quote for about the last 9
months. I honestly don't know where I got it, or whether I invented
it independently. I don't think I've ever seen an episode of "Yes
Minister".

Most Google hits for the quotation are occurrences of my sig quote;
when I filter those out there are still a few dozen hits, some
referring to it as the "politician's syllogism".

Possibly the writer of that episode got it from somewhere else.

 

[Malcolm]

I suspect that I'm not the only clc subscriber to have used C on
non-ASCII systems and have had no problems in this regard.

How would you make strlen() return the length of a Unicode string on a
system where bytes are naturally 8 bits?

 

[infobahn]

How would you make strlen() return the length of a Unicode string on a
system where bytes are naturally 8 bits?

That's a very different question. If you meant "supporting a
character set other than the one directly offered by the
implementation", then I agree it's another matter entirely.

 

[infobahn]

Obviously you have polluted the data base. "Yes, Minister" was a
very funny right-pondian effort seen on PBS in left-pondia some
years ago.

Furthermore, the episode in question pre-dates net.lang.c, never
mind comp.lang.c.

 

[Mark McIntyre]

I've been utilising C for lots of small and a few medium-sized personal
projects over the course of the past decade, and I've realised lately
just how little progress it's made since then. I've increasingly been
using scripting languages (especially Python and Bourne shell)

Good. In that case, go post your comments in python and unix groups. This
group is to discuss using C, not to discuss why you're not using it.

C has no string type. Huh? Most sane programming languages have a
string type which allows one to just say "this is a string"

C++ is thataway --->

Functions for insignificant operations

Ask yourself how C++ copies a string.

The encouragement of buffer overflows

This remark can only be made by a non-C programmer.

Functions which encourage buffer overflows

and which any actual C programmer knows to avoid and/or treat with care.

* bcopy()
* getwd()
* getopt()
* realpath()
* getpass()

and these ones aren't even C functions.

No builtin boolean type

Wrong. check out stdbool.h

If you don't believe me, just watch: .....
test.c:3: 'bool' undeclared (first use in this function)

So, try using the right type. Thats simply a fatuous mistake.

Integer overflow without warning
--------------------------------

Self explanatory. One minute you have a fifteen digit number, then try
to double or triple it and - boom - its value is suddenly
-234891234890892 or something similar. Stupid, stupid, stupid.

Yeah, of the programmer.

How hard
would it have been to give a warning or overflow error or even just
reset the variable to zero?

If its so easy, you do it. Remember your solution has to work on anything
from a DSP to a Cray, via a Vax and an 8086.

Please. There are at least four official specifications of C I could
name from the top of my head and no compiler has properly implemented
all of them. They conflict, and they grow and grow.

And this differs from any other programming language.... how?

Archaic, unexplained conventions

such as using good progamming practice.

Blaming The Progammer

when he screws up, who else to blame?

C is over thirty years old,

Apart from the revision in 1999 of course. C++ meanwhile is how old? And
bourne shell is, er, over thirty, and python is.... what was your point
exactly?

It lacks features that modern
languages have such as exception handling, many useful data types,
function overloading, optional function arguments and garbage
collection.

Ignoring the fact that much of this is useless on many of C's target
architectures, I again wonder how this differs from other languages. BTW
don't bullshit anyone here, we mostly programme in all of them, you'll be
caught.

 

[Mark McIntyre]

It's all well and good saying this, but if the language itself is
packed with booby traps

Its not, its just that you're incompetent at it. Sorry, but if you think
your statement to be true, then it is the only remaining conclusion.

and requires every element of the entire body
of code to be meticulously planned out to avoid bugs,

It doesn't, any more than any othe language does./

it's inevitable
that no large program in the language will avoid introducing at least
one bug.

This is true of ANY programme in any language. Its an axiom.

 

[Kenny McCormack]

It is not the language that is prone to crashing constantly, if anything
is crashing it is your program. The solution is to write better programs.
Blaming ones own lack of skills on the tools are not productive.

"It is a poor workman that blames his tools". Yes, as true now as ever.

Having said that, the only sense in which the OP's obvious trolling is at
all worthwhile is by taking it from a manager's perspective (that is, not
from a programmer's perspective).

While it is certainly true that it is a poor workman who blames his tools,
it *is* legitimate to criticize the tools chosen by and used by OTHER
PEOPLE, especially if you are paying the salaries of those OTHER PEOPLE.

So, I invite you all to continue this discussion from that perspective.

 

[evolnet.regular]

:It's all well and good saying this, but if the language itself is
acked with booby traps and requires every element of the entire body
f code to be meticulously planned out to avoid bugs, it's inevitable
:that no large program in the language will avoid introducing at least
ne bug.

I don't recall hearing that people had gotten very far with
automated proof of correctness in *any* Turing-equivilent
programming language. Proofs have a way of exploding badly
with even very small programs, due to branch points -- each
branch point potentially doubles the size of the proof,
and loops can imply indefinite branching.

Consider for example, the amount of effort needed to prove
the correctness of these few lines:

while ( md5(x) != 0 ) x = md5(x);

Thus it is pretty much inevitable that large programs in *any*
useful programming language will have at least one bug. Even in
very highly refined and constrained languages that are built as
academic projects in programming and metaprogramming to avoid bugs.

True, but my point is:

(1) C introduces entirely new classes of bugs
and
(2) C makes bugs more likely, regardless of the programmer's skill
and
(3) C makes it much harder to root out and fix bugs

and I still haven't seen any reasoning against this.

 

[evolnet.regular]

In that case, why is it that there are so many buffer overflows in so
many C programs written by presumably experienced coders and yet so few
in programs written in *any other language*?

 

[Joona I Palaste]

(e-mail address removed) scribbled the following

In that case, why is it that there are so many buffer overflows in so
many C programs written by presumably experienced coders and yet so few
in programs written in *any other language*?

I find it hard to believe there are more buffer overflows in C programs
than there are in assembly programs. Unless you don't count assembly as
a language.

 

[evolnet.regular]

There are fewer buffer overflows in assembly programs because people
don't overuse assembly language as they do C.

 

[Steven]

There are fewer buffer overflows in assembly programs because people
don't overuse assembly language as they do C.

We are talking proportions here! The percentage remains the same
regardless of the sample size! A simple understanding of mathematics
will probably be good for you!

Assembly language is pure power, the only reason people don't use it
often is because the portability and *difficulty* of the language. But
if speed is called for, like a arbitrary-precision library, what
language is used for the core routines? Assembly. If you are too
babish to learn to use the power, fine, get a Mac program in Java!!

Give anyone power and it can be misused. C assumes the programmer is
*COMPETENT*, and therefore C tries not to provide too much overhead and
sometimes unneccessary processes in the program. You are responsible
for how the program runs, checking the bounds, checking for errors,
etc, not the compiler. The compiler does exactly what you tell it to
do without trying to outsmart you. That is about as close you can get
to machine language without assembly. If you're not smarter than the
compiler at trying to control your program, you're better off not
programming.

Booby traps? Like those nonexistant (or at least rarely used)
functions (where did you find those functions, and why do you even use
them)? Power and efficency itself is a booby trap. Who said writing
in C should be easy, it is not called a mid-level programming language
for nothing.

If you think something is hard, don't learn it and don't complain.
Just because you are lacking in intelletual aptitude doesn't mean none
of us have the intelletual aptitude program in C either.

Power or simplicity comes at a price. Look at Java: huge library, OOP,
garbage-collection, exception-checking, portability, etc. All nice and
dandy. But what happened to its flexibility? What happened to its
speed? Can you do *ANY* low level manipulation? What happens when you
what a low-level routine? It not so simple anymore, is it? You can't
even easily do a conditional compilation. Even C++ has big flaws, how
many memory leaks have you seen in a well written C program!

I am still puzzled by your post. What did you expect to accomplish?
Attract attention to yourself? Make us feel sorry for you
incompetence? Tell the world about you inability to accept power?
Nothing is free in life, and POWER COMES AT A COST!!

 

[Chris Torek]

How would you make strlen() return the length of a Unicode string on a
system where bytes are naturally 8 bits?

It already does. It returns the length in (C) bytes (units of
"char"). The fact that it takes up to 4 C bytes to encode a single
display position is another matter entirely; and if you want columns
to line up, you need something more than "number of display positions"
anyway, because Unicode fonts are (at least mostly) proportional.

(I suspect, however, that infobahn was referring to EBCDIC on
IBM mainframes. C works fine there, although plain char must be
unsigned, because, e.g., '0' == 0xf0, and CHAR_BIT is still 8.
EBCDIC does break a lot of programs that assume 'I'+1 == 'J',
though.)

 

[CBFalconer]

Walter Roberson wrote:
.... snip ...

True, but my point is:

(1) C introduces entirely new classes of bugs and
(2) C makes bugs more likely, regardless of the programmer's
skill and
(3) C makes it much harder to root out and fix bugs

and I still haven't seen any reasoning against this.

Please do snip what you quote, especially sig lines.

C is no worse in these respects than assembly language, except when
it tries to ape higher level languages and do things behind your
back. A case in point is the hidden arithmetic promotions.

So it is well to think of C as a portable structured assembly
language with an extensive library. That way you probably won't
get hurt, unless you do something foolish like using unsigned bit
fields and expecting them to act unsigned.

 

[CBFalconer]

In that case, why is it that there are so many buffer overflows in
so many C programs written by presumably experienced coders and yet
so few in programs written in *any other language*?

For the same reasons that most automobile accidents have a
teen-ager at the heart of it. Teen-ager implies novice. Today
that teenager gets a copy of "Dummies Learn C in 28 minutes", or
some other BullSchildt, together with a whiz bang IDE, and
laboriously create a "Hello World" that occupies 0.25 megabytes
[1]. They now cackle fatuosly and go to work for General Crap
Software. Some of them in this very newsgroup even claim to work
for NASA and jpl.

[1] While in the days of CP/M a "Hello World" could be about 25
bytes. It need not be appreciably larger today.

 

[Walter Roberson]

ower or simplicity comes at a price. Look at Java: huge library, OOP,
:garbage-collection, exception-checking, portability, etc. All nice and
:dandy. But what happened to its flexibility? What happened to its
:speed? Can you do *ANY* low level manipulation? What happens when you
:what a low-level routine? It not so simple anymore, is it? You can't
:even easily do a conditional compilation.

We had a programming team here who put in several person years of
efforts into writing their scientific programs in Java, thinking that
the OOP facilities together with the strong type checking and
prevention of array and buffer overflows would help them to produce
good and useful code. They also took care to use the "self-documenting"
style to embed documentation in the code, and they took code metrics
an so on -- in other words, the project had definite elements of
"software engineering" rather than just a bunch of people throwing
code together.

The project in that form was given up after roughly three years.
They reclaimed a bunch of the APIs they had developed [the OOP was
certainly not a complete waste], but they are now rewriting in
pure C++ (with perhaps the occasional C module.) Even with the most
advanced JIT compilers they could find, and using all the Java tricks
they could think of, they simply couldn't get enough speed in
the portions of the code that needed to extract portions of
multidimensional arrays for processing. No pointers in Java,
remember, and no pointer arithmetic, so there were no opportunities
to take advantage of any knowledge of in-memory layout of their
multidimensional arrays: at each step they had to create
a new vector of the proper length, loop copying the data into the
vector, and pass the vector in to the work routine. With datasets
starting at 1/2 Gb and destined to get much larger, the memory moves
were killing their efficiency completely, and there was -no-
way in Java around it.

Strongly typed langauges with semi-opaque data structures that
exist to enforce "correct code" and hide differences such as
the '.' operator vs the -> operator, usually sooner or later get
into the way when there is massive of work to be done.

[The only reason I say 'usually' rather than 'always' is that
it would not be impossible to define a higher level language
that offered "handles" by reference into multidimensional
data, that did subscript checking and yet knew how to efficently
map "vector" accesses into hidden pointer arithmetic to get at
the real data.]

 

[Michael Mair]

In that case, why is it that there are so many buffer overflows in
so many C programs written by presumably experienced coders and yet
so few in programs written in *any other language*?

For the same reasons that most automobile accidents have a
teen-ager at the heart of it. Teen-ager implies novice. Today
that teenager gets a copy of "Dummies Learn C in 28 minutes", or
some other BullSchildt, together with a whiz bang IDE, and
laboriously create a "Hello World" that occupies 0.25 megabytes
[1]. They now cackle fatuosly and go to work for General Crap
Software. Some of them in this very newsgroup even claim to work
for NASA and jpl.

[1] While in the days of CP/M a "Hello World" could be about 25
bytes. It need not be appreciably larger today.

Darn, I made it never below 1/2K (including standard startup and cleanup
code)...

-Michael