"Criticism of the C programming language ??????"

C

Charlton Wilbur

aa> Hi all, I found an interesting article here:-
aa> http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language

aa> well what do you guys think of this article....??? Is it
aa> constructive criticism that needs to be appreciated
aa> always...???

Just about everything on that list was an intentional design choice --
either because it provided some benefit that would otherwise be lost,
because alternative approaches required too much trading off, or
because it made porting C compilers easier to other platforms.

If you find that enough of the things on that list cause you problems,
then C is not the language you should be using. Fortunately, there
are a broad variety of computer languages to choose from, and nobody
is forcing you to use C.

Charlton
 
A

asit

Hi all,

I found an interesting article here:-http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language

well what do you guys think of this article....???
Is it constructive criticism that needs to be appreciated always...???


i agree with this article. but C is good when it comes low level
programming like system programming. but u have to compromise on some
features.
 
S

Serve Lau

Charlton Wilbur said:
aa> Hi all, I found an interesting article here:-
aa>
http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language

aa> well what do you guys think of this article....??? Is it
aa> constructive criticism that needs to be appreciated
aa> always...???

Just about everything on that list was an intentional design choice --
either because it provided some benefit that would otherwise be lost,
because alternative approaches required too much trading off, or
because it made porting C compilers easier to other platforms.

If you find that enough of the things on that list cause you problems,
then C is not the language you should be using. Fortunately, there
are a broad variety of computer languages to choose from, and nobody
is forcing you to use C.

Most points are just personal opinions. There could be a wiki too, "good
aspects of the C language" and it could say

syntax
no GC
many absent features
has pointers
economy of expression

etc.
 
P

Paul Hsieh

Hi all,

I found an interesting article here:-http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language

well what do you guys think of this article....???

This article barely touches upon the poorly design library, esp. the
lack of re-entrancy and no-aliasing issue, or the conflict created
with C++ with the complex numbers introduced in C99. There is no
mention of the fact that this supposedly "portable" language is most
often used in non-portable custom implementations. For example, C is
heavily used for dynamically loaded device drivers -- but the dynamic
loading part is always platform dependent.
Is it constructive criticism that needs to be appreciated always...???

Well clearly as there is no further forward development of the C
language, this is mostly just a lot of hot air. But it can serve as a
useful platform for other language designers to know what *NOT* to do.
 
J

jacob navia

Paul said:
This article barely touches upon the poorly design library, esp. the
lack of re-entrancy and no-aliasing issue, or the conflict created
with C++ with the complex numbers introduced in C99. There is no
mention of the fact that this supposedly "portable" language is most
often used in non-portable custom implementations. For example, C is
heavily used for dynamically loaded device drivers -- but the dynamic
loading part is always platform dependent.


Well clearly as there is no further forward development of the C
language, this is mostly just a lot of hot air. But it can serve as a
useful platform for other language designers to know what *NOT* to do.

Not everybody agrees that C is dead and there is no further development.

You are in good company however.

In this group, the official position of the "regulars" is precisely
that:

no new development, back to C 1990, etc.

I have tried (in this group and in comp.std.c) to argue against
that position. I can't say that I have succeeded.
 
J

jacob navia

Charlton said:
Just about everything on that list was an intentional design choice --
either because it provided some benefit that would otherwise be lost,
because alternative approaches required too much trading off, or
because it made porting C compilers easier to other platforms.

If you find that enough of the things on that list cause you problems,
then C is not the language you should be using. Fortunately, there
are a broad variety of computer languages to choose from, and nobody
is forcing you to use C.

Charlton

This attitude is the basic error: The obvious shortcommings are always
answered with "go away"... "Use another language", etc.

And (obviously too) not even the shadow of an argumentation.
 
K

Kenny McCormack

This attitude is the basic error: The obvious shortcommings are always
answered with "go away"... "Use another language", etc.

And (obviously too) not even the shadow of an argumentation.

Ultimately, though, that's the way things are. Ultimately, you realize
that the thing is not going to change and so you either adapt yourself
to it, or look elsewhere.

Note that "the thing" in question here is the attitude(s) in this
newsgroup. I am not talking about the C programming language (something
we almost never discuss here either).

Think of this ng as like a church. Church people have very rigid
(generally 13th century [*]) views on things. They ain't gonna change.

[*] If you're lucky. 13th century for Christians. 8th century for,
e.g., Muslims.
 
P

Paul Hsieh

Not everybody agrees that C is dead and there is no further
development.

I have followed some number of your posts, and it seems to me that you
might be heading more towards where Walter Bright is going with his "D
language". It seems, like him, you want to make the language better
by virtue of semantic and syntactical changes, with true language
function augmentation.

My angle is different. There is a reasonable language hiding
somewhere in there, but it needs to be fixed. What I want to do is
plug all the stupid holes (start defining things that are currently
undefined), create a fully functional modification of the C library
that is fully re-entrant, have mandated runtime debugging assistance
and vastly expanded functionality for the heap, expose standard
functionality available on most modern CPUs (and which is otherwise
emulatable), redesign the file-IO for generic I/O (so that "FILE as
memory" emulation or sockets can happen fully at the library level)
and implement "one shot continuations" style coroutines into the
language. And fix glaring stupidities like ftell() and fseek() using
long as the file pointer offset.

In other words I just want to make the language to be a whole hell of
a lot better at doing what it already does today, and start making it
less suck at what it sucks at today. Most of what I want can be
solved with a better library alone.

But people are just satisfied with C for some reason. In the years of
posting here I have barely had any support for my point of view. It
kind of disturbs me that nobody cares about any of these issues. So
its not like any of this would ever make it into a proposal which
would be considered by the ANSI C committee. As they say and have
demonstrated themselves, they are concerned with putting a rubber
stamp on standard practice (totally ignoring the chicken and egg
problem inherent with this), and only venturing to do new things if
endorsed by some bizarre lobby that has absolutely no significant user
support (like MS's safe string stuff.)
You are in good company however.

Well I am *resigned* to the fact that nothing is going to happen.
Other people actually don't care and seem pretty happy with the status
quo.
In this group, the official position of the "regulars" is precisely
that:

no new development, back to C 1990, etc.

Well not exactly. They seemed really keen on complex numbers that put
them in direct conflict with the C++ standard. As long as it breaks C+
+ or has other anti-social effects, they seem more that willing to
adopt it.
I have tried (in this group and in comp.std.c) to argue against
that position. I can't say that I have succeeded.

Methinks there isn't a strong enough lobby for rationality in the
continued development of the C standard. And getting them to
acknowledge problems? I mean they are going to finally get rid of
gets() in the next standard. So they can no longer support any of
their prior claims that there was some good reason for it to be
there. They just have to admit, that they just left it in there for
18 years. Yay them for getting rid of gets(), but if that's how long
it takes, making the C library re-entrant is just never going to
happen.
 
M

Martin Ambuhl

jacob said:
You are in good company however.

In this group, the official position of the "regulars" is precisely
that:

no new development, back to C 1990, etc.

I have tried (in this group and in comp.std.c) to argue against
that position. I can't say that I have succeeded.


Since there is no one taking the position that Jacob asserts to be 'the
official position of the "regulars"', you have a clue about how much you
can trust anything he writes. No one pays attention to his arguments in
comp.lang.c because they are inevitably about his private language,
implemented on his compiler for sale for commercial use, or completely
wrongheaded. It is never because anyone is wedded to "no new
development, back to C 1990, etc." That he identifies any disagreement
with his flights of fancy as that tells you much more about him than
about this group.
 
M

Mark McIntyre

This attitude is the basic error: The obvious shortcommings

What you mean is "the things I regard as shortcomings, and which I
refuse to accept others might disagree with me about".
are always answered with "go away"...

Generally falsee, and specifically false in this case to boot.
But don't let the facts stop your paranoia.
"Use another language", etc.

Correct. Do you go fishing with a curling iron ? Do you curl your hair
with a hook ?
And (obviously too) not even the shadow of an argumentation.

You might want to consider whether you have any " argumentation"
yourself. Especially given that its not a word.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

Not everybody agrees that C is dead and there is no further development.

Correct.
In this group, the official position of the "regulars" is precisely that:

Absolutely, the official postition of the regulars is that we don't
agree that C is dead and that there is no further development. Oh,
wait, you were being /ironic/. In which case you lie again.
I have tried (in this group and in comp.std.c) to argue against
that position. I can't say that I have succeeded.

Not actually. Mostly you've tried to discuss offtopic garbage in
comp.lang.c, and when asked to stop, you've been either offensive or
arrogant. The other thing you've done is showed your ignorance of some
aspects of the language.

From what I hear, over in CSC you've merely been shot down for talking
bollocks and/or being clueless. ICBW of course.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

Hi all,

I found an interesting article here:-
http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language

well what do you guys think of this article....???

We discussed this some time back.

Many of the "deficiencies" listed are either deliberate design
decisions in the interests of efficiency, compactness and speed, or
viewed by many as /strengths/ of the language.

Take for example the "Absent Features" section. This lists a lack of
graphics, networking and multithreading as if they were weaknesses. If
you're designing a language for a standalone non-networked single-CPU
embedded environment, how could you add these features ?

The section on undefined behaviour is hilarious. The writer seems to
think that C is alone in leaving some behaviour undefined. Thats
utterly wrong.
Is it constructive criticism that needs to be appreciated always...???

Read it, and remember its a Wikipedia article and therefore represents
the POV of whoever edited it last. As it happens Doug Gwyn seems to
have put in a fair amount of effort on the page, and its better than
it was when I first looked at it, but some of it is still precisely
the sort of stuff that Wikipedia claims not to want - ie personal
opinion, not fact.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
P

Peter Nilsson

[Please cite the context of your replies.]

Chris Thomasson said:
Without C and Assembly Language, how are we to
prototype anything new?

Same way we prototype new cheesecakes without tomato sauce.

Neither C nor (any) Assembly Language are particularly
favoured for prototyping new applications.
 
C

Chris Thomasson

Peter Nilsson said:
[Please cite the context of your replies.]

Chris Thomasson said:
Without C and Assembly Language, how are we to
prototype anything new?

Same way we prototype new cheesecakes without tomato sauce.

Neither C nor (any) Assembly Language are particularly
favoured for prototyping new applications.

How does do you prototype a new Garbage Collector Algorithms without
low-level languages ;like Assembly, C/C++?
 
S

santosh

Chris said:
Without C and Assembly Language, how are we to prototype anything new?

Actually C and assembler are probably more often used for final
production than prototyping. In recent times prototyping
and "proof-of-concept" are most often done in an interpreted language.

The exponential increase in computing capacity has resulted in "heavier"
languages becoming acceptable for day-to-day use, thus eating
significantly into the niche that C monopolised back in the 70s and
80s.

However C is still a favoured language for systems programming. However
since systems and embedded work are largely "invisible" to the majority
of computer users and newbie programmers, a feeling is created that C
has "died" or is "dying".

The tenacious persistence of COBOL and FORTRAN should tell us that C is
likely to be used actively for a long time and supported for an even
longer time.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,051
Latest member
CarleyMcCr

Latest Threads

Top