Discussing the criticisms

[jacob navia]

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.

 

[CBFalconer]

.... 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?

 

[CBFalconer]

.... 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.

 

[Ian Collins]

-----
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.

 

[jacob navia]

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
(e-mail address 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/TechRpts/2006/EECS-2006-1.html
January 10, 2006

 

[Richard Harter]

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 address 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/TechRpts/2006/EECS-2006-1.html
January 10, 2006
---------------------------------------------------

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



Richard Harter, (e-mail address 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

 

[user923005]

http://www.stanford.edu/class/cs240/readings/threads-bad-usenix96.pdf


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

Richard Harter, [email protected]://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.

 

[Mark McIntyre]

-------------------------------------------------------------------
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.

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.

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

 

[Peter Nilsson]

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.

 

[jacob navia]

<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.

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.

 

[Keith Thompson]

jacob navia wrote:
[...]

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...

[...]

My failure to produce a real-world example does not prove, does not even
*suggest*, that no such example exists.

If you propose a change to the language that *could* break existing
portable code, you should mention that. That's all I was saying. I
didn't even suggest that GC (either as an extension or as a new language
feature) is a bad idea. *All* I said is that if you're going to use GC,
you have to be a bit more careful about how you handle pointers, and
that this fact should not be ignored.

I made a minor technical point and you blew it completely out of proportion.

 

[Richard Bos]

We had another thread discussing the criticisms to C in a
wikipedia article.

Yes, we did. So why are you creating yet another thread to spout your
preconceptions? Why not use that, perfectly good, existing, thread to do
so? What reason to cause more needless clutter in this newsgroup's topic
list? Whence this habit that you seem to have picked up the last couple
of months? It is not clever, it is not nice, it is not honest, and
you're not doing yourself any favours by it. Knock it off already. When
you have something to add to a thread - _do so_. Don't force it to spill
over into more and more threads full of bumf and bluster.

Richard

 

[Nick Keighley]

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

....with a pointer to the actual paper
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

 

[Philip Potter]

JUST POLEMIC. When I say that GC doesn't need any changes to the

Let he who is without sin cast the first stone.

 

[Spiros Bousbouras]

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.

If that's what you really want to do then I'm afraid that
you chose an entirely hopeless way of doing it. Each of the
issues you mention could very well occupy a big thread
on its own and some of them actually have , in fact some
have occupied several threads. So are you really hoping that
a constructive discussion can ensue where all of these will
be discussed in parallel ??? The best scenario I can
envision for this thread is that it will be ignored , the worse
(and sadly the most likely) is that it will lead to hundreds
of posts with all people talking about all kinds of issues
most of them out of topic.

From your long list I will only quote 1 item below.

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 quite disagree with the threads is a mistake part
(although this particular thread is) but it deserves a
thread on its own and it should be on comp.programming
not here.

 

[Eric Sosman]

jacob navia wrote On 11/15/07 18:30,:

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.

Perhaps people are weary of argument.

I am not sneering at the value of the opinion of other people,

.... and a few lines later ...

All of them took their usual negative attitude

.... and that sort of thing I, for one, find wearisome.

 

[jacob navia]

jacob navia wrote On 11/15/07 18:30,:

Perhaps people are weary of argument.


... and a few lines later ...


... and that sort of thing I, for one, find wearisome.

Me too. It would be better that people tried to be positive,
show arguments for their opinions, and at least TRIED to
explain why they arrive at their conclusions.

Just saying

"It will not work"

Or

"C is like that. Take it or leave it"

doesn't bring anybody further in the discussion.


The discussion about the abstract data types was destroyed by
Heathfield and Co, in the usual manner. They did not propose
a single bit of code, let people work and just limited
themselves to a negative attitude that eventually destroyed
the positive discussion that the people that proposed a standard
interface for lists etc did.

People brought their coden worked to get something out of this
group, and they were just ignored by these people
that of course were right: nothing came out of it.

After destroying the dicussion, they were right. It just
can't be done.

Great.

Then, abstracting away all this facts you say:

> ... and that sort of thing I, for one, find wearisome.

Poor Eric. I am so sad for you.

 

[Richard Harter]

...with a pointer to the actual paper
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

Thanks, I missed that. Still, it would have been better to give
the URL of the actual paper.


Richard Harter, (e-mail address 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

 

[Eric Sosman]

jacob navia wrote On 11/16/07 11:22,:

jacob navia wrote On 11/15/07 18:30,:


Perhaps people are weary of argument.



... and a few lines later ...



... and that sort of thing I, for one, find wearisome.

Me too. It would be better that people tried to be positive,
show arguments for their opinions, and at least TRIED to
explain why they arrive at their conclusions.
[...]

Perhaps I didn't express myself clearly. By "that
sort of thing" I did not mean the negative attitudes (a
negative attitude toward gets(), for example, is fully
justified), but your gratuitous use of "their usual
negative attitude," an inflammatory if not downright
insulting remark.

Your usual combative, antagonistic, insensitive,
and egomaniacal, twaddle wearies me. (Note that I
am not sneering, oh, no, not I.)

 

[Richard]

jacob navia wrote On 11/15/07 18:30,:

Perhaps people are weary of argument.


... and a few lines later ...


... and that sort of thing I, for one, find wearisome.

Agreed. They should try to remain open minded before doing the
habitual closing of ranks.