Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > "Criticism of the C programming language ??????"

Reply
Thread Tools

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

 
 
santosh
Guest
Posts: n/a
 
      11-15-2007
In article <(E-Mail Removed)>, Chris
Thomasson <(E-Mail Removed)> wrote on Thursday 15 Nov 2007 9:10 am:

> "Peter Nilsson" <(E-Mail Removed)> wrote in message
>

news:(E-Mail Removed)...
>> [Please cite the context of your replies.]
>>
>> "Chris Thomasson" <(E-Mail Removed)> wrote:
>>> 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++?


No. This can be done any language like Java or Python, though presumably
the final implementation might be in C.

 
Reply With Quote
 
 
 
 
Chris Thomasson
Guest
Posts: n/a
 
      11-15-2007
"santosh" <(E-Mail Removed)> wrote in message
news:fhgfk8$cs1$(E-Mail Removed)...
> In article <(E-Mail Removed)>, Chris
> Thomasson <(E-Mail Removed)> wrote on Thursday 15 Nov 2007 9:10 am:
>
>> "Peter Nilsson" <(E-Mail Removed)> wrote in message
>>

> news:(E-Mail Removed)...
>>> [Please cite the context of your replies.]
>>>
>>> "Chris Thomasson" <(E-Mail Removed)> wrote:
>>>> 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++?

>
> No. This can be done any language like Java or Python, though presumably
> the final implementation might be in C.
>


How do you create a GC in a language that requires a GC?

 
Reply With Quote
 
 
 
 
jfbode@austin.rr.com
Guest
Posts: n/a
 
      11-15-2007
On Nov 14, 11:03 am, (E-Mail Removed) wrote:
> 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...???


The criticisms presented in that article are, for the most part,
valid. The only ones I'll quibble with are the lack of object-
oriented programming support; that's to be expected in a language that
wasn't designed to be object-oriented.

As others have pointed out, many of the weaknesses pointed out in the
article were results of deliberate design decisions. At the time, it
was more important that the language be small, fast, and easily ported
to other platforms rather than be fully featured.

All that means is that C is better suited to some tasks than others.
For example, text processing in C is a royal pain in the ass; C
doesn't define a native string type, for one thing, and the string
processing routines are rudimentary at best.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-15-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
....
> article were results of deliberate design decisions. At the time, it
> was more important that the language be small, fast, and easily ported
> to other platforms rather than be fully featured.


Those characteristics continue to be important in many contexts, and it
is precisely in those contexts that C continues to flourish.
 
Reply With Quote
 
Szabolcs Nagy
Guest
Posts: n/a
 
      11-15-2007

(E-Mail Removed) wrote:
> All that means is that C is better suited to some tasks than others.
> For example, text processing in C is a royal pain in the ass; C
> doesn't define a native string type, for one thing, and the string
> processing routines are rudimentary at best.


not a good example
the fact that the standard does not contain certain functionality does
not mean one can not implement them simply and efficiently

for high level tasks obviously you'll need libraries, where you can
hide the complexity behind a well designed api (and you can do it in c
pretty well)

actually many string processing applications and libraries are written
in c
(eg applications: sed, awk, grep, perl; libraries: bstring, tre, ..)
 
Reply With Quote
 
Charlton Wilbur
Guest
Posts: n/a
 
      11-15-2007
>>>>> "PH" == Paul Hsieh <(E-Mail Removed)> writes:

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

PH> But people are just satisfied with C for some reason. In the
PH> years of posting here I have barely had any support for my
PH> point of view. It kind of disturbs me that nobody cares about
PH> any of these issues. So its not like any of this would ever
PH> make it into a proposal which would be considered by the ANSI
PH> C committee.

The ANSI C committee has to consider millions of lines of existing
code, and backwards compatibility. It also has to contend with the
overwhelming yawn that came from the compiler-writing community in
response to C99.

I understand that you want a better language; why does it matter to
you that this better language is called C? What is it about the name
C and the ANSI imprimatur that is so valuable, that means you can't
create your own new language, with all the problems fixed, and call it
something else? There's precedent for this, you know: C++ and
Objective-C trod the same ground decades ago. Java started out as a
redesigned C++; Ruby started out as a redesigned Perl.

The reactions to your and Jacob's improvements to C has a very simple
explanation: they require tradeoffs that just don't make sense in a
lot of contexts. C is good enough in a lot of ways; more importantly,
the places where it's not good and the edge cases where it gets
pathological are well known. If you make major sweeping changes to
the language itself, suddenly that's not the case, and the only thing
New C has in common with Old C is the name.

In other words: people do care about the issues you care about, but
we're just addressing them by using other languages when the other
language is a better choice, not by altering C to suit.

So why can't you and Jacob design your new perfect languages and call
them something other than C?

Charlton


--
Charlton Wilbur
(E-Mail Removed)
 
Reply With Quote
 
Charlton Wilbur
Guest
Posts: n/a
 
      11-15-2007
>>>>> "CT" == Chris Thomasson <(E-Mail Removed)> writes:

CT> How do you create a GC in a language that requires a GC?

The same way you produce a compiler for a new language that requires a
compiler: you bootstrap it from lower levels.

Charlton


--
Charlton Wilbur
(E-Mail Removed)
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-15-2007
Charlton Wilbur wrote:
>>>>>> "PH" == Paul Hsieh <(E-Mail Removed)> writes:

>
> PH> In other words I just want to make the language to be a whole
> PH> hell of a lot better at doing what it already does today, and
> PH> start making it less suck at what it sucks at today. Most of
> PH> what I want can be solved with a better library alone.
>
> PH> But people are just satisfied with C for some reason. In the
> PH> years of posting here I have barely had any support for my
> PH> point of view. It kind of disturbs me that nobody cares about
> PH> any of these issues. So its not like any of this would ever
> PH> make it into a proposal which would be considered by the ANSI
> PH> C committee.
>
> The ANSI C committee has to consider millions of lines of existing
> code, and backwards compatibility. It also has to contend with the
> overwhelming yawn that came from the compiler-writing community in
> response to C99.
>
> I understand that you want a better language; why does it matter to
> you that this better language is called C?


I understand that you want a bad language. Why you want to call it C?
You say that any improvements to C should be in the official improvement
language for C: C++ isn't it?

All the time that anyone proposes an improvement the same lame
argument from the same people:

Why you want to improve something bad by design?

Just leave it like that. gets() is OK, needs no improvement.

> What is it about the name
> C and the ANSI imprimatur that is so valuable, that means you can't
> create your own new language, with all the problems fixed, and call it
> something else?


Why it is so that if you want a bad language you create your own and
allow other people to improve C?

> There's precedent for this, you know: C++ and
> Objective-C trod the same ground decades ago. Java started out as a
> redesigned C++; Ruby started out as a redesigned Perl.
>


You can innovate. Call your language C--.

> The reactions to your and Jacob's improvements to C has a very simple
> explanation: they require tradeoffs that just don't make sense in a
> lot of contexts.


This has never been said before. I do not see what tradeoffs
you are talking about. The introduction of improved libraries
like a malloc where you can query the size of an object as proposed
by Paul would make sense and take no overhead.


> C is good enough


for YOU

> in a lot of ways; more importantly,
> the places where it's not good and the edge cases where it gets
> pathological are well known.


Yes. And please do not improve them. Just make your new
language C-- and leave us in peace ok?


> If you make major sweeping changes to
> the language itself, suddenly that's not the case, and the only thing
> New C has in common with Old C is the name.
>


Nobody is talking about your "sweeping changes", just you.

> In other words: people do care about the issues you care about, but
> we're just addressing them by using other languages when the other
> language is a better choice, not by altering C to suit.
>


C must retain all its badly designed choices because you say so.
And people that propose improvements (that you do not even care
to say that are wrong!) are juust making a new language of course.
There is nothing worst than a new language that simplifies an old
one and makes it better. Yes.


> So why can't you and Jacob design your new perfect languages and call
> them something other than C?


I do not speak for Mr Hsieh but why should I?

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Charlton Wilbur
Guest
Posts: n/a
 
      11-15-2007
>>>>> "JN" == jacob navia <(E-Mail Removed)> writes:

JN> I understand that you want a bad language. Why you want to
JN> call it C? You say that any improvements to C should be in
JN> the official improvement language for C: C++ isn't it?

Because the language already exists, and has been called C for the
past three decades.

JN> All the time that anyone proposes an improvement the same lame
JN> argument from the same people:

JN> Why you want to improve something bad by design?

JN> Just leave it like that. gets() is OK, needs no improvement.

No: the question is, what will this improvement cost us? We know why
you want to improve it, because you harangue us at length; we may even
agree with your rationale. But there are millions, possibly billions
of lines of C code out there, and hundreds of C compilers, and if you
make a change that isn't backwards compatible, *someone* has to go and
deal with those millions of lines of code and hundreds of C compilers.

>> What is it about the name C and the ANSI imprimatur that is so
>> valuable, that means you can't create your own new language,
>> with all the problems fixed, and call it something else?


JN> Why it is so that if you want a bad language you create your
JN> own and allow other people to improve C?

The language C already exists, and is reasonably well-defined.

JN> This has never been said before. I do not see what tradeoffs
JN> you are talking about. The introduction of improved libraries
JN> like a malloc where you can query the size of an object as
JN> proposed by Paul would make sense and take no overhead.

In a new compiler, sure. In all new code, sure. What happens when
someone writes code with this new feature and tries to run it on an
old compiler?

>> In other words: people do care about the issues you care about,
>> but we're just addressing them by using other languages when
>> the other language is a better choice, not by altering C to
>> suit.


JN> C must retain all its badly designed choices because you say
JN> so. And people that propose improvements (that you do not
JN> even care to say that are wrong!) are juust making a new
JN> language of course. There is nothing worst than a new
JN> language that simplifies an old one and makes it better. Yes.

No: C must retain all its badly designed choices because there are
millions of lines of code and hundreds of compilers that implement
them. I *don't* think your improvements are wrong, in the large; I
think that adding them to C is likely to break a lot of things, and
even if it doesn't, it will require updating a lot of compilers; thus
unless the cost of the change is less than the benefit of the change
is worth, the change should not be made.

If you're playing with even 100,000 lines of code and one compiler,
the tradeoffs are different.

>> So why can't you and Jacob design your new perfect languages
>> and call them something other than C?


JN> I do not speak for Mr Hsieh but why should I?

Because you'll get a lot farther that way. Because you might get your
new language into widespread use, instead of coming across as a crank.

You still haven't answered the basic question: why is the C name and
the ANSI imprimatur so important to you?

Charlton


--
Charlton Wilbur
(E-Mail Removed)
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-15-2007
Charlton Wilbur wrote:
>>>>>> "JN" == jacob navia <(E-Mail Removed)> writes:

>
> JN> I understand that you want a bad language. Why you want to
> JN> call it C? You say that any improvements to C should be in
> JN> the official improvement language for C: C++ isn't it?
>
> Because the language already exists, and has been called C for the
> past three decades.
>
> JN> All the time that anyone proposes an improvement the same lame
> JN> argument from the same people:
>
> JN> Why you want to improve something bad by design?
>
> JN> Just leave it like that. gets() is OK, needs no improvement.
>
> No: the question is, what will this improvement cost us? We know why
> you want to improve it, because you harangue us at length; we may even
> agree with your rationale. But there are millions, possibly billions
> of lines of C code out there, and hundreds of C compilers, and if you
> make a change that isn't backwards compatible, *someone* has to go and
> deal with those millions of lines of code and hundreds of C compilers.
>


You still haven't proved that any change that I have proposed makes
some code go wrong. As far as I know the syntax
int operator[](Array tabv,int idx);

is not used in single line in those billions of C code lines.
Since we can do
#define operator __operator
we only use an already reserved word, and a new syntax. This
can't do any harm to any existing code.


>
> JN> This has never been said before. I do not see what tradeoffs
> JN> you are talking about. The introduction of improved libraries
> JN> like a malloc where you can query the size of an object as
> JN> proposed by Paul would make sense and take no overhead.
>
> In a new compiler, sure. In all new code, sure. What happens when
> someone writes code with this new feature and tries to run it on an
> old compiler?


And what happens if I try to use a compiler that still doesn't accept
prototypes?

It doesn't work. Great! Let's get rid of prototypes then!

Why you would try to use new code with an old compiler?
This is a data processing field, not an association for the
religious worship of old code!

>
> >> In other words: people do care about the issues you care about,
> >> but we're just addressing them by using other languages when
> >> the other language is a better choice, not by altering C to
> >> suit.

>
> JN> C must retain all its badly designed choices because you say
> JN> so. And people that propose improvements (that you do not
> JN> even care to say that are wrong!) are juust making a new
> JN> language of course. There is nothing worst than a new
> JN> language that simplifies an old one and makes it better. Yes.
>
> No: C must retain all its badly designed choices because there are
> millions of lines of code and hundreds of compilers that implement
> them. I *don't* think your improvements are wrong, in the large; I
> think that adding them to C is likely to break a lot of things, and
> even if it doesn't, it will require updating a lot of compilers;


OK. You agree that it will NOT break anything. Your arguments now
reduce to the price of retooling the compilers... I mean that
is a significant shift in your argumentation.

> thus
> unless the cost of the change is less than the benefit of the change
> is worth, the change should not be made.
>


The cost of maintaining C code is staggering because of those
problems precisely. It require from the programmer a LOT of time
and attention to do all those allocations and freeings without a single
error.

The improvements to C would make it easier to use, the user base would
grow. Yes, there are zillions of old code but the people doing C
are less and less and everybody is associating the C language
with overflow bugs...

C applications could be rewritten using the new features slowly, and
they would improve.

Or, (and that is what you and many other people want) no improvements
would be done to either the language or the applications until they
disappear. C would disappear faster than Cobol and Fortran, since
even Cobol has improved, and Fortran accepts now operator overloading
and allows a modern style of programming.

But that would be in an horizon of 10 years from now, so nobody cares.
Let's freeze C until it dies away.


> If you're playing with even 100,000 lines of code and one compiler,
> the tradeoffs are different.
>
> >> So why can't you and Jacob design your new perfect languages
> >> and call them something other than C?

>
> JN> I do not speak for Mr Hsieh but why should I?
>
> Because you'll get a lot farther that way. Because you might get your
> new language into widespread use, instead of coming across as a crank.
>


I am only "a crank" in this group. My compiler system is used by many
people, I have arrived at 500 000 downloads of this system. Users
from Chine, U.S., many universities, single people, etc. And they like
it because the language is simple, modern, and the whole download is
just 5MB. It is fast, and produces small executables.

Yes, there are still people that appreciate that, and like to use
simple things.

C has a future, and I am convinced of that and I will work for that
goal. ANd if I am considered "a crank" by people in this group
I do not care at all about their opinions!



> You still haven't answered the basic question: why is the C name and
> the ANSI imprimatur so important to you?
>
> Charlton
>
>



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Sorry for interrupt,because my mother language is not English,it maybe a little confused to read the c programming language. Zhang Yuan C Programming 6 06-14-2012 04:35 AM
Can Your Programming Language Do This? Joel on functional programming and briefly on anonymous functions! Casey Hawthorne Python 4 08-04-2006 05:23 AM
A language-agnostic language Ed Java 24 03-27-2006 08:19 PM
Using a Scripting Language as Your Scripting Language DaveInSidney Python 0 05-09-2005 03:13 AM
Python is the best and most popular general purpose scripting language; the universal scripting language Ron Stephens Python 23 04-12-2004 05:32 PM



Advertisments