Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Discussing the criticisms

Reply
Thread Tools

Discussing the criticisms

 
 
jacob navia
Guest
Posts: n/a
 
      11-15-2007
We had another thread discussing the criticisms to C in a
wikipedia article. No one from this group really addressed
those criticisms besides the usual "nonsense" and similar
contributions.

With this post I want to go a bit deeper into those, at least
address them individually.
-------------------------------------------------------------------
The mentioned wiki article mentions following criticism to the C
language:

1: No assignment of arrays or strings (copying can be done via standard
functions; assignment of objects having struct or union type is supported)

This is a justified criticism. The basic problem is the C handling of
arrays, that makes very difficult to work with those arrays in a
rational manner.

Suggested solution:
Within the context of lcc-win, I have proposed to overload operators,
what makes it possible to use arrays with automatic bounds checking,
supporting assignment and many other normal features.

The solution is the same for strings since strings are just special
cases of arrays.

From a language point of view (consistency) there is absolutely no
reason to make this distinction between arrays and structures. The
standard answer is:
"If you want to assign an array to another put it into a structure"

typedef struct tag S{ int array[512]; } MyArray;

Then you can do
My array a,b;
....//
a = b;

Why must be done that way? There is no justification to that.
-----
-----
2: No requirement for bounds checking of arrays

See above. The same solution (operator overloading of the indexing
operator) is proposed for arrays and strings.
The proposed solution allows also a normal handling of arrays as
first class objects without any "decay" nonsense.
-----
-----
3: No syntax for ranges, such as the A..B notation used in several
languages

This is not justified. Many languages exist where ranges aren't
supported. This is, in any case, a minor problem if at all.
-----
-----
4: No separate Boolean type: zero/nonzero is used instead.

This has been fixed with the C99 standard. The article complains that
it hasn't been "retrofitted" but that is quite impossible IMHO.
-----
-----
5: No nested function definitions.
I do not see why this is a problem. Even if some C dialects support this
feature (the GNU compiler) it doesn't solve any existing problem.
-----
-----
6: No formal closures or functions as parameters (only function and
variable pointers)
Closures would complexify the language. If needed, it can be
simulated with a structure containing the state variables you want to
capture from the environment, and a function pointer.
-----
-----
7: No generators or coroutines; intra-thread control flow consists of
nested function calls, except for the use of the longjmp or setcontext
library functions

This is not needed. Coroutines can be programmed in C, but there is no
language support
-----
-----
8: No exception handling; standard library functions signify error
conditions with the global errno variable and/or special return values

This is a correct critique. Structured exception handling is necessary
in most environments.
Lcc-win supports __try/__except in the same manner as the Microsofts
constructs. Maybe there will be standard support for a form of
exception handling since the committee started studying the Microsoft
extensions.
-----
-----
9: Only rudimentary support for modular programming
This is too harsh. The support in the form of file delimited modules is
enough. Other solutions (line namespaces) complexify the language
and have conceptual problems
-----
-----
10: No compile-time polymorphism in the form of function or operator
overloading
This is a justified criticism, that lcc-win addresses by providing
overloaded (polymorphic) functions and operator overloading.
-----
-----
11: Only rudimentary support for generic programming
Lcc-win tries to address this with overloaded functions and operator
overloading. See above.
-----
-----
12:No direct support for object-oriented programming with regard to
polymorphism or inheritance, although a limited form of these may be
achieved with type punning.

C is not object oriented. There is NO NEED for yet another OO
language, but THERE IS A NEED for a NON OO language.
-----
-----
13: Limited support for encapsulation.
The support is enough. Module separation is one, and the abstract data
type ( struct foo is another. Both are sufficient.
-----
-----
14: No native support for multithreading and networking
This is ridiculous. Most networking libraries are in C! Multithreading
support would be a mistake, since threads are a mistake.
-----
-----
15: No standard libraries for graphics and several other application
programming needs.

This is ridiculous. Who needs "standard graphics libraries" ?
There are many standards, and all are accessible by C programs.
-----
-----
All in all there are some valid criticisms in that article, and I have
tried to address them within the lcc-win compiler.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      11-15-2007
jacob navia wrote:
>

.... snip ...
>
> 1: No assignment of arrays or strings (copying can be done via
> standard functions; assignment of objects having struct or union
> type is supported)
>
> This is a justified criticism. The basic problem is the C
> handling of arrays, that makes very difficult to work with those
> arrays in a rational manner.
>
> Suggested solution:
> Within the context of lcc-win, I have proposed to overload
> operators, what makes it possible to use arrays with automatic
> bounds checking, supporting assignment and many other normal
> features.


Ignoring the fouling of standard C, consider: How do you
differentiate between copying the string address (a pointer) and
copying the string? How does the recipient tell these cases apart?

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      11-15-2007
jacob navia wrote:
>

.... snip ...
>
> 3: No syntax for ranges, such as the A..B notation used in several
> languages
>
> This is not justified. Many languages exist where ranges aren't
> supported. This is, in any case, a minor problem if at all.
>

.... snip ...
>
> 5: No nested function definitions.
> I do not see why this is a problem. Even if some C dialects support this
> feature (the GNU compiler) it doesn't solve any existing problem.


Item 3 is serious, if you want to have proper range checking.
Item 5 solves many problems. Consider:

outer procedure(params) {

int count;

statoc inner recursiveprocedure(parms) {
count++;
while (whatever) recursiveprocedure(parms);
return something;
}

count = 0;
recursiveprocedure(parms);
return count;
}

which does recursive processing with private variables fully
protected against accidental access.

While you may not approve of some of the C characteristics, they
have evolved into a self-consistent and usable set. In most cases
you can't avoid them without hideous contortions. Some abilities
are unnecessary, and only cause compiler complication, such as
scopes that begin and end with '{' and '}'. file and function
scope is adequate, and would discourage the building of oversized
functions.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-15-2007
jacob navia wrote:
> -----
> 14: No native support for multithreading and networking
> This is ridiculous. Most networking libraries are in C! Multithreading
> support would be a mistake, since threads are a mistake.
> -----


I'll ignore the rest, but "since threads are a mistake" is utter nonsense.

--
Ian Collins.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-15-2007
Ian Collins wrote:
> jacob navia wrote:
>> -----
>> 14: No native support for multithreading and networking
>> This is ridiculous. Most networking libraries are in C! Multithreading
>> support would be a mistake, since threads are a mistake.
>> -----

>
> I'll ignore the rest, but "since threads are a mistake" is utter nonsense.
>


I will leave the arguments for the experts, specially
reference (2)

(1)
Why Threads Are A Bad Idea (for most purposes)
John Ousterhout
Sun Microsystems Laboratories
http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.sunlabs.com/~ouster
1996 USENIX Technical Conference
(January 25, 1996)
(2)
----------------------------------------------------
The Problem with Threads
Edward A. Lee
Electrical Engineering and Computer Sciences
University of California at Berkeley
Technical Report No. UCB/EECS-2006-1
http://www.eecs.berkeley.edu/Pubs/Te...CS-2006-1.html
January 10, 2006
---------------------------------------------------


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Richard Harter
Guest
Posts: n/a
 
      11-15-2007
On Thu, 15 Nov 2007 20:52:18 +0100, jacob navia
<(E-Mail Removed)> wrote:

>Ian Collins wrote:
>> jacob navia wrote:
>>> -----
>>> 14: No native support for multithreading and networking
>>> This is ridiculous. Most networking libraries are in C! Multithreading
>>> support would be a mistake, since threads are a mistake.
>>> -----

>>
>> I'll ignore the rest, but "since threads are a mistake" is utter nonsense.


Codswallop.

>>

>
>I will leave the arguments for the experts, specially
>reference (2)
>
>(1)
>Why Threads Are A Bad Idea (for most purposes)
>John Ousterhout
>Sun Microsystems Laboratories
>(E-Mail Removed)
>http://www.sunlabs.com/~ouster
>1996 USENIX Technical Conference
>(January 25, 1996)
>(2)
>----------------------------------------------------
>The Problem with Threads
>Edward A. Lee
>Electrical Engineering and Computer Sciences
>University of California at Berkeley
>Technical Report No. UCB/EECS-2006-1
>http://www.eecs.berkeley.edu/Pubs/Te...CS-2006-1.html
>January 10, 2006
>---------------------------------------------------


Check your URLs. The first is broken and the second is an
abstract.



Richard Harter, (E-Mail Removed)
http://home.tiac.net/~cri, http://www.varinoma.com
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die
 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      11-15-2007
On Nov 15, 12:27 pm, (E-Mail Removed) (Richard Harter) wrote:
> On Thu, 15 Nov 2007 20:52:18 +0100, jacob navia
>
> <(E-Mail Removed)> wrote:
> >Ian Collins wrote:
> >> jacob navia wrote:
> >>> -----
> >>> 14: No native support for multithreading and networking
> >>> This is ridiculous. Most networking libraries are in C! Multithreading
> >>> support would be a mistake, since threads are a mistake.
> >>> -----

>
> >> I'll ignore the rest, but "since threads are a mistake" is utter nonsense.

>
> Codswallop.
>
>
>
>
>
>
>
> >I will leave the arguments for the experts, specially
> >reference (2)

>
> >(1)
> >Why Threads Are A Bad Idea (for most purposes)
> >John Ousterhout
> >Sun Microsystems Laboratories
> >(E-Mail Removed)
> >http://www.sunlabs.com/~ouster
> >1996 USENIX Technical Conference
> >(January 25, 1996)
> >(2)


http://www.stanford.edu/class/cs240/...d-usenix96.pdf

> >----------------------------------------------------
> >The Problem with Threads
> >Edward A. Lee
> >Electrical Engineering and Computer Sciences
> >University of California at Berkeley
> >Technical Report No. UCB/EECS-2006-1
> >http://www.eecs.berkeley.edu/Pubs/Te...CS-2006-1.html
> >January 10, 2006
> >---------------------------------------------------

>
> Check your URLs. The first is broken and the second is an
> abstract.
>
> Richard Harter, (E-Mail Removed)://home.tiac.net/~cri,http://www.varinoma.com
> In the fields of Hell where the grass grows high
> Are the graves of dreams allowed to die- Hide quoted text -


The "Threads are Bad" article does not suggest the elimination of
threads. It suggests using threads when threads should be used and
using events when events should be used. I guess that Jacob did not
bother to read it but liked the catchy title.

 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      11-15-2007
jacob navia wrote:
> -------------------------------------------------------------------
> The mentioned wiki article mentions following criticism to the C
> language:
>
> 1: No assignment of arrays or strings (copying can be done via standard
> functions; assignment of objects having struct or union type is supported)
>
> This is a justified criticism. The basic problem is the C handling of
> arrays, that makes very difficult to work with those arrays in a
> rational manner.


Well I disagree. It is /not/ difficult to handle arrays in C. I

> Suggested solution:
> Within the context of lcc-win, I have proposed to overload operators,


If you want to extend the language, suggest it over in CSC, whre I
should imagine you'll get reminded that there are *already* languages
not dissimilar to C that offer this feature.

> -----
> 8: No exception handling; standard library functions signify error
> conditions with the global errno variable and/or special return values
>
> This is a correct critique. Structured exception handling is necessary
> in most environments.


SEH is nice, but far from essential. It also makes little sense in many
envrionments.

> -----
> 9: Only rudimentary support for modular programming
> This is too harsh.


Frankly, you're too lenient.

> 10: No compile-time polymorphism in the form of function or operator
> overloading
> This is a justified criticism,


No its not. The language doesn't support this. Why should it?

> -----
> 12:No direct support for object-oriented programming
>
> C is not object oriented. There is NO NEED for yet another OO
> language, but THERE IS A NEED for a NON OO language.


Agreed.

> -----
> 14: No native support for multithreading and networking
> This is ridiculous. Most networking libraries are in C! Multithreading
> support would be a mistake, since threads are a mistake.


Ignoring the last rater weird comment, I agree with you.

> -----
> 15: No standard libraries for graphics and several other application
> programming needs.
>
> This is ridiculous. Who needs "standard graphics libraries"


Agreed.

> All in all there are some valid criticisms in that article,


If you'd stopped typing here, you;d have been topical.

>and I have tried to address them within the lcc-win compiler.


but converting your commentary into an advert for your product was a mistake

 
Reply With Quote
 
Peter Nilsson
Guest
Posts: n/a
 
      11-15-2007
jacob navia <(E-Mail Removed)> wrote:
> We had another thread discussing the criticisms to C
> in a wikipedia article. No one from this group really
> addressed those criticisms besides the usual "nonsense"
> and similar contributions.


<sigh>

Yet again, your tactic to engage an audience is to open
with a sneer on the value of their opinion!

If you're failing to get people to take you and your
articles seriously, then look inwards, not outwards,
to discover why.

--
Peter
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-15-2007
Peter Nilsson wrote:
> jacob navia <(E-Mail Removed)> wrote:
>> We had another thread discussing the criticisms to C
>> in a wikipedia article. No one from this group really
>> addressed those criticisms besides the usual "nonsense"
>> and similar contributions.

>
> <sigh>
>
> Yet again, your tactic to engage an audience is to open
> with a sneer on the value of their opinion!
>
> If you're failing to get people to take you and your
> articles seriously, then look inwards, not outwards,
> to discover why.
>
> --
> Peter


I said that most answers did not even try to have a technical discussion
about the issues addressed in the critique of the wikipedia article but
remained in the level of summary answers without any substantial
argumentation.

I am not sneering at the value of the opinion of other people, I just
say that they could have put more argumented answers. In general, (and
your post is surely not an exception) the technical level of the
discussion here is incredible low.

Either we start discussing some homework and we solve it brilliantly for
the lazy students that post their homework here, or we start endless
polemic about non-issues. When there is a long critic of the language
published in the wikipedia, the regulars start the usual "who cares"
"use another language" "go away", etc.

I would like to remind people the attitude of the regulars when the
discussion about a common abstract data types interface started.

All of them took their usual negative attitude without ever proposing
something or at least trying to justify technically their arguments.

Just general stuff like "it will not work" "I told you so" etc.

I took the time of presenting a complete solution (with extensive source
code) of a solution that represented a genral CLASS of solutions, that
was easily extensible and complete. NOT ONE of the "regulars" answered
anything, mainly because they are unable to argument anything.

JUST POLEMIC. When I say that GC doesn't need any changes to the
language, K. Thomson (that is one of the most reasonable of them)
says that programs that store pointers in files or elsewhere *could*
be broken by a GC. And he adds without noticing the irony that of course
he can't find any real world examples of such a program...
In short:
I was saying that I do not agree with this type of discussion and wanted
to answer the criticism of C in detail.


--
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
[OT] which newsgroup(s) for discussing continuous integration? marlow.andrew@googlemail.com Java 2 11-07-2008 04:25 PM
Group for Discussing about boost library Sarath C++ 5 02-22-2007 08:53 PM
Just as we were discussing the Pentax ist-D... Mark Roberts Digital Photography 2 01-31-2004 12:48 AM
Discussing what I post Tracker Computer Security 5 10-02-2003 03:56 PM



Advertisments