Why C Is Not My Favourite Programming Language

[Keith Thompson]

One of the great things about C is that you can become a true master in it,
precisely because it has many pitfalls.

Another way to put that is that you *have* to become a true master in
C, precisely because it has many pitfalls.

 

[Servé La]

Another way to put that is that you *have* to become a true master in
C, precisely because it has many pitfalls.

heh, no I dont agree with that. Nobody has to do anything. One can always
choose another language if they dant wanna become good at C

 

[Keith Thompson]

heh, no I dont agree with that. Nobody has to do anything. One can always
choose another language if they dant wanna become good at C

Yes, there are always choices. What I meant was that if you're going
to program in C, you can either become a "true master" in C, or you
can risk running into its many pitfalls.

This is, of course a gross oversimplification. A more accurate
statement might be that C is less friendly to beginners than many
other languages.

 

[evolnet.regular]

Another way to put that is that you *have* to become a true master in
C, precisely because it has many pitfalls.

Exactly right.

The only problem is that there's no longer a gradual transition period
between "total newbie" and "true master" as there is with most
languages. You have to use and study C intensely for years before you
can safely be let loose with it. As such, it's simply not a practical
language for the vast majority of people.

 

[Keith Thompson]

Exactly right.

In another followup, I said that that was a gross oversimplification.

Incidentally, "evolnet.regular", you've never responded to the posts
in which several people pointed out that your original lengthy article
was identical to an article posted by someone else on Kuro5hin, and
that you didn't mention this or credit the (presumed) original author.
Would you care to explain?

 

[infobahn]

The only problem is that there's no longer a gradual transition period
between "total newbie" and "true master" as there is with most
languages.

Yes, there is. There's a big range of knowledge. Look in comp.lang.c
for evidence thereof.

You have to use and study C intensely for years before you
can safely be let loose with it. As such, it's simply not a practical
language for the vast majority of people.

No language is a practical language for the vast majority of people.
And you have to use and study any language intensely for years before
you can safely be let loose with it.

The fact that people /are/ let loose earlier than this is reflected
in the poor quality of so many programs for which the copyright
owners have the gall to charge money. Some people have no shame.

 

[Richard Bos]

The only problem is that there's no longer a gradual transition period
between "total newbie" and "true master" as there is with most
languages. You have to use and study C intensely for years before you
can safely be let loose with it.

This is true for all other programming languages as well; the greatest
difficulty of programming lies not in syntax and bookkeeping, but in
algorithmic design. The great advantage of C is that it makes it
immediately obvious whether one is a master or an apprentice.

Richard

 

[evolnet.regular]

Gladly.

I originally wrote this article. I figured it would seem
self-aggrandizing to credit myself with having written it so I didn't
originally mention it.

Hope this helps.

 

[evolnet.regular]

"Yes, there is. There's a big range of knowledge. Look in comp.lang.c
for evidence thereof. "

From what I've seen, it's more like somebody asking a relatively

innocent question, followed by 25 other people leaping in with a
barrage of "OH MY GOODNESS THAT IS NOT IN THE STANDARD LEAVE THIS
NEWSGROUP NOW". Two people subsequently get in a back and forth
argument over footnotes in a random ANSI/ISO/POSIX standard. This
doesn't happen with other languages. Why?


"No language is a practical language for the vast majority of people."

This is true, but irrelevant. There are also many people who are
entirely capable of programming if the language is reasonably well
designed.

"And you have to use and study any language intensely for years before
you can safely be let loose with it. "

Not really. All it takes is good documentation and some intelligence
and you can write safe and secure programs in most mid-level or
high-level languages such as Java, Python, PHP, Perl, and the like.
Just remember not to trust user input and to debug properly.

Why aren't there as many security holes in getmail as fetchmail, for
instance? Why are there so few security holes in major programs of
every other language put together compared to those written in C or C++?

 

[Mark McIntyre]

On 11 Feb 2005 15:30:48 -0800, in comp.lang.c , (e-mail address removed)
wrote:

(Stuff)

Troll. Alert.

 

[evolnet.regular]

If people don't want to hear the answer, they oughtn't ask the
question.

 

[Walter Roberson]

:From what I've seen, it's more like somebody asking a relatively
:innocent question, followed by 25 other people leaping in with a
:barrage of "OH MY GOODNESS THAT IS NOT IN THE STANDARD LEAVE THIS
:NEWSGROUP NOW".

That line has a grain of truth to it.

:Two people subsequently get in a back and forth
:argument over footnotes in a random ANSI/ISO/POSIX standard. This
:doesn't happen with other languages. Why?

Partly because there aren't that many ISO standardized languages.

There is:

ISO 1989:2002 Programming Language Cobol

ISO 1539-1:1997 "Fortran 95"
ISO 1539-1:2004 Fortran 2003
ISO 1539-2:2002 Fortran Standard part 2 (varying length strings)
ISO 1539-3:1998 Fortran Standard part 3 (conditional compilation)
ISO 7846:1985 Industrial real-time Fortran (withdrawn)

ISO 8652:1995 Ada
ISO 13813:1998 Generic Packages of Real and Complex Type Declarations
and Basic Operations for Ada
ISO 15291:1999 Ada Semantic Interface Specification
ISO 18009:1999 Conformity Assessment of an Ada Language Processor

ISO 13816:1997 Programming Language ISLISP

ISO 13211-1 Programming Language Prolog part 1 -- General Core

ISO 14882 Programming Language C++

ISO 7185:1990 Pascal
ISO 10206:1991 Extended Pascal

ISO 10514-1:1996 Modula-2 (Base Language)
ISO 10514-2:1998 Modula-2 (OO extension)
ISO 10514-3:1998 Modula-2 (Generic extension)

ISO 1538:1984 Programming Langauge Algol 60 (withdrawn)

ISO 10279:1991 Programming Language BASIC

ISO 4335 Programming Language PL/1

There is also an active working group on APL.

It is interesting that of the "serious" living languages,
only ISLISP, C, and C+ are specified by a single standard: the rest
require multiple standards.

Ada, of course, had the design goal that there would be NO Ada
varients, that -every- Ada implimentation would be able to compile
-every- Ada program and that they would all behave exactly the same way.

Fortran... I can't say that it is obvious to me why one would need
an entire standard to deal with varying length strings.


What is of particular interest is that all of the languages that you
had submitted as being better than C are absent. No international
standard for Java, Python, Perl, Tcl. ksh is, I suppose, specified
as part of one of the POSIX standards (POSIX.2 maybe?), but it is
not easy to write meaningful programs in pure ksh without calling
upon outside programs such as sed or nawk or test.

 

[infobahn]

"Yes, there is. There's a big range of knowledge. Look in comp.lang.c
for evidence thereof. "

innocent question, followed by 25 other people leaping in with a
barrage of "OH MY GOODNESS THAT IS NOT IN THE STANDARD LEAVE THIS
NEWSGROUP NOW".

Then you don't understand the dynamics of the group.

Two people subsequently get in a back and forth
argument over footnotes in a random ANSI/ISO/POSIX standard. This
doesn't happen with other languages. Why?

Perhaps that's because, in comp.lang.c, we enjoy discussing the
dark corners of the language (often as a reminder to ourselves not
to use them!).

"No language is a practical language for the vast majority of people."

This is true, but irrelevant. There are also many people who are
entirely capable of programming if the language is reasonably well
designed.

Yes; DWIM will be very popular if it ever gets past the vapourware
stage.

"And you have to use and study any language intensely for years before
you can safely be let loose with it. "

Not really.

Oh dear oh dear oh dear.

All it takes is good documentation and some intelligence
and you can write safe and secure programs in most mid-level or
high-level languages such as Java, Python, PHP, Perl, and the like.
Just remember not to trust user input and to debug properly.

(a) that isn't all there is to it; (b) those last two points alone
take a very long time to get right.

Why aren't there as many security holes in getmail as fetchmail, for
instance?

If that's true (and I haven't studied the sources of the two programs
in question), it's probably because the fetchmail author put more
security holes into his program than the getmail author did into his.

Why are there so few security holes in major programs of
every other language put together compared to those written in C or C++?

(a) You don't actually know this for a fact, because nobody knows
how many security holes any large non-trivial program has, irrespective
of the language in which it's written.
(b) Security holes are most easy to exploit, and therefore -
eventually - to come to non-exploiters' attention, in networking
programs. Most non-trivial networking programs are written in C.
(Warning: about to invent some random numbers) Headline: C programs
responsible for 80% of security holes! Small print: 90% of programs
are written in C. It is easy to ignore the small print, and imagine
that we can cut 80% of security holes by banning C, but if you do
the numbers you'll find that this just isn't true.

In fact, experienced C programmers are well aware of the ways in
which security holes can occur. The "point, click, and see what
happens" approach to programming which you appear to advocate is
much /more/ likely to lead to security problems.

 

[infobahn]

If people don't want to hear the answer, they oughtn't ask the
question.

Which answer to what question?

 

[Keith Thompson]

Gladly.

I originally wrote this article. I figured it would seem
self-aggrandizing to credit myself with having written it so I didn't
originally mention it.

Hope this helps.

Ok, thanks for the clarification. So you're James A C Joyce?

I fail to see how it would be "self-aggrandizing" to claim credit for
something you wrote; if it hadn't appeared on Kuro5hin, we would have
assumed you wrote it anyway.

 

[Mabden]

(e-mail address removed) scribbled the following


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.

My axiom:
C is a Master's Language. Simple, Elegant, Powerful. Like a handgun. In
the right hands, it executes perfectly. In the wrong hands, it simply
executes.

My opinion:
The idea of why C bugs may be seen more often than "other" languages, is
simple. Everything you use is written in C. Your Perl translator was
written in C, as was your Visual Basic compiler. Whatever you think is
"safe" probably has a lot of C code in it. Certainly your C++ compiler
does (also, probably mostly straight C / ASM).

 

[Nicolas Pavlidis]

My axiom:
C is a Master's Language. Simple, Elegant, Powerful. Like a handgun. In
the right hands, it executes perfectly. In the wrong hands, it simply
executes.

My Problem with C is the following:
If you want to write robust, extedible and safe code, the code gets a
bit unreadable very fast. This problem is shared by all procedual
languages, allthough C has more conzepts to write such code than other
languages of this kind.

My opinion:
The idea of why C bugs may be seen more often than "other" languages, is
simple. Everything you use is written in C. Your Perl translator was
written in C, as was your Visual Basic compiler. Whatever you think is
"safe" probably has a lot of C code in it. Certainly your C++ compiler
does (also, probably mostly straight C / ASM).

Thats true, but it is often better to use other languages to get the
result, as using C, because of the reason I said before.

Kind regards,
Nicolas

 

[Chris Croughton]

My Problem with C is the following:
If you want to write robust, extedible and safe code, the code gets a
bit unreadable very fast.

That better describes Perl. Well, apart from the bits about robust and
safe code...

This problem is shared by all procedual
languages, allthough C has more conzepts to write such code than other
languages of this kind.

C is one of few languages which even has a standard. And it's one of
few modern languages which even has a compiler (Perl, Python and Java
are interpreted, which is why they are 'safe' in some fashion because
the interpreter can check for things like invalid accesses -- at the
cost of speed and complexity elsewhere). They can also be more
'extendable' that way (FORTH is the ultimate extendable language), but
that isn't always an advantage (I've heard FORTH -- and Perl --
programmers praising the language because they can "write things no one
else can understand" by using their own extensions, as though that is a
good thing).

Thats true, but it is often better to use other languages to get the
result, as using C, because of the reason I said before.

No, it is sometime better to use other languages for specific tasks
because those languages are better at those specific tasks. I wouldn't
write a web CGI program in C, I'd use PHP because it's designed for
that; if I wanted heavy number crunching I'd still use Fortran (or
assembler for the specific platform); if I want string and shell
handling I use AWK or Perl; etc.

No language is perfect. No editor is perfect, nor is any operating
system or CPU. They are all compromises and they are designed for and
best at certain tasks.

A good programmer should know many different programming languages, and
know the strengths and weaknesses of them for the programs required. It
is rare that a programmer gets a completely free hand (often the choice
of language is up to management) but there are often opportunities for a
programmer to choose the best for a specific job (at my work we have
some using Perl, some using Java, some using C and some using C++, for
different jobs; I use C for portable code, Awk and C++ (and Unix/POSIX
utilities) for local utilities and processing).

Chris C

 

[Dave Vandervies]

"And you have to use and study any language intensely for years before
you can safely be let loose with it. "

Not really. All it takes is good documentation and some intelligence
and you can write safe and secure programs in most mid-level or
high-level languages such as Java, Python, PHP, Perl, and the like.
Just remember not to trust user input and to debug properly.

You missed designing and writing code properly. That will avoid a lot
more problems (safety-related or not) than even good debugging will
ever catch.
And all it takes is good documentation and some intelligence and you
can write safe and secure programs in C. Just remember not to trust
user input and to design, write, and debug your program properly.

Why are there so few security holes in major programs of
every other language put together compared to those written in C or C++?

Perhaps because there are so few major programs at all in every other
language?


dave

 

[Walter Roberson]

:In article <[email protected]>,

:>"And you have to use and study any language intensely for years before
:>you can safely be let loose with it. "

:>Not really. All it takes is good documentation and some intelligence
:>and you can write safe and secure programs in most mid-level or
:>high-level languages such as Java, Python, PHP, Perl, and the like.

:You missed designing and writing code properly.

S/he also missed the problem that Perl doesn't *have* good documentation.

Documentation it has, but there are so many different interactions
possible between the features that you need a fair bit of experience to
write solid maintainable perl programs that are also somewhat efficient.

The poster should try reading the 'perlgolf' contest entries sometime...

http://perlgolf.sourceforge.net/