Discussing the criticisms
jacob navia
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
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.
--
Ian Collins.
jacob navia
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
john.ou...@eng.sun.com
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
<ja...@nospam.com> 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
>john.ou...@eng.sun.com
>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, c...@tiac.net
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
> On Thu, 15 Nov 2007 20:52:18 +0100, jacob navia
>
> <ja...@nospam.com> 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
http://www.stanford.edu/class/cs240/readings/threads-bad-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/TechRpts/2006/EECS-2006-1.html
> >January 10, 2006
> >---------------------------------------------------
>
> Check your URLs. The first is broken and the second is an
> abstract.
>
> Richard Harter, c...@tiac.nethttp://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.
> -----
> 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
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.
--
Peter
jacob navia
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
[...]
> 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.
--
Keith Thompson (The_Other_Keith) <ks...@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
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
> On Thu, 15 Nov 2007 20:52:18 +0100, jacob navia
> <ja...@nospam.com> 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.
> >>> -----
<snip>
> >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
> >john.ousterh...@eng.sun.com
> >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.
...with a pointer to the actual paper
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
--
Nick Keighley
Philip Potter
> Peter Nilsson wrote:
>> jacob navia <ja...@nospam.com> 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.
>
Let he who is without sin cast the first stone.
--
Philip Potter pgp <at> doc.ic.ac.uk
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
>
> 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
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
Thanks, I missed that. Still, it would have been better to give
the URL of the actual paper.
Eric Sosman
> Eric Sosman wrote:
>
>>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.
>>
>
>
>
> 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
Agreed. They should try to remain open minded before doing the
habitual closing of ranks.
Richard
> jacob navia wrote On 11/16/07 11:22,:
>> Eric Sosman wrote:
>>
>>>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.
>>>
>>
>>
>>
>> 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.
Get off your high horse. Do you read some of the comments? Jacob is
right.
>
> Your usual combative, antagonistic, insensitive,
> and egomaniacal, twaddle wearies me. (Note that I
> am not sneering, oh, no, not I.)
And you accuse Jacob of being insulting? All he suggested were some
"negative comments". Which are, incidentally, evident in the thread.
Richard Heathfield
<snip>
> Your usual combative, antagonistic, insensitive,
> and egomaniacal, twaddle wearies me. (Note that I
> am not sneering, oh, no, not I.)
I'm okay with "combative" (although it would be more pleasant to be fellow
seekers-after-truth). I can handle "antagonistic" (although it would be
more pleasant to have friendly discussions with friendly people), I don't
have a problem with "insensitive" (although it would be more pleasant to
be sensitive to others), and I am no stranger to "egomaniacal" (although
it would be more pleasant to recognise that others, too, have pride in
their knowledge, experience, accomplishments, and skill).
But it's the twaddle, Eric. I just can't hack the twaddle, the utter
drivel, that pours out in a seemingly endless stream. "Wearies" is
precisely the word.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Default User
> jacob navia <ja...@nospam.com> wrote:
>
> > 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 do people keep responding to his efforts? He does this to get a
reaction. Reacting feeds the cycle. He posts his crap and gets a 40
message thread out of it. What possible reason would he have for
stopping.
It's obvious that disapproval means nothing to him. The only way to get
Jacob to stop this sort of nonsense is to have his efforts disappear
into the ether with nary an impact on the group. Then it becomes a
waste of his time because he won't get the attention he craves.
Some of us have taken to plonking him. I realize that some don't want
to do that, either so they can correct him when he replies to newbies
or to "encourage" his on-topic efforts. The latter seems to have little
or no beneficial effect. A short, standard message about him posted in
response to off-topic posting (with no follow-up) would be sufficient
in my opinion.
Brian
user923005
wrote:
Here is the conclusion of the paper:
"8 Conclusion
Concurrency in software is difficult. However, much of this difficulty
is a consequence of the abstractions for concurrency that we have
chosen to use. The dominant one in use today for generalpurpose
computing is threads. But non-trivial multi-threaded programs are
incomprehensible to humans. It is true that the programming model can
be improved through the use of design patterns, better granularity of
atomicity (e.g. transactions), improved languages, and formal methods.
However, these techniques merely chip away at the unnecessarily
enormous nondeterminism of the threading model. The model remains
intrinsically intractable. If we expect concurrent programming to be
mainstream, and if we demand reliability and predictability from
programs, then we must discard threads as a programming model.
Concurrent programming models can be constructed that are much more
predictable and understandable than threads. They are based on a very
simple principle: deterministic ends should be accomplished with
deterministic means. Nondeterminism should be judiciously and
carefully introduced where needed, and should be explicit in programs.
This principle seems obvious, yet it is not accomplished by threads.
Threads must be relegated to the engine room of computing, to be
suffered only by expert technology providers."
My paraphrasal:
Threads are hard to understand. Only smart people should program with
threads.
My rebuttal:
I write threaded code every day (basically, everything I write runs in
threaded environments), so it can't be that difficult.
Threads consume less resources than processes. Furthermore, the new
wave of horsepower seems to be derived from multiple CPUs and multiple
cores on the CPUs.
My summary:
We had better get used to threads.
jacob navia
> Richard Bos wrote:
>
>> jacob navia <ja...@nospam.com> wrote:
>>
>>> 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 do people keep responding to his efforts?
Well, maybe (just maybe) because what I do is not
wrong.
People that do not have any arguments try to intimidate me
(the anonymous attacks against myself and my family posted
in September) or try to ignore me (as the ridiculous attempts
of Heathfield and co) and it doesn't work.
Damm!
"The dogs bark but... the caravan goes on"
rose...@mailinator.com
> Default User wrote:
> > Richard Bos wrote:
> >
> >> jacob navia <ja...@nospam.com> wrote:
> >>
> >>> 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 do people keep responding to his efforts?
>
> Well, maybe (just maybe) because what I do is not
> wrong.
Yeah right, you keep telling yourself that.
>
> People that do not have any arguments try to intimidate me
> (the anonymous attacks against myself and my family posted
> in September) or try to ignore me (as the ridiculous attempts
> of Heathfield and co) and it doesn't work.
Well cry me a fricking river! You were the one who brought your family
into it, by announcing to all of Usenet that your daughter downloads
Japanese pornography in breach of copyright laws.
You have started two threads on an ill-informed, badly written and
generally stupid Wikipedia article (you weren't a contributor to it by
any chance?), which has already been discussed to death in the past in
this group. There can be absolutely no reason for this other than to
provoke a further flame war from those in the group who actually know
something about C.
You're like a dog returning to its own vomit - this persecution
complex you've built up for yourself needs to be constantly fueled by
well-deserved abuse you get when you post trash to this group.
If life had an AGC, you'd be the first bit of useless memory swept up
and thrown back onto the heap, just in case something useful could be
put in its place.
>
> Damm!
>
> "The dogs bark but... the caravan goes on"
If I were you, I'd go and see a psychiatrist. Oh, and go learn
something about C while you're at it.
J. J. Farrell
> 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.
Indeed. Perhaps I'm not reading very well tonight, but to my eyes
Ousterhout seems to be saying "instead of threads you should use
threads; and what's more you should use threads in exactly the way
you've always used threads". Ousterhout is arguing against a particular
style of programming with threads, certainly not against the use of threads.
It is hard to read his "Should You Abandon Threads? No" as "threads are
a mistake".
Keith Thompson
> Default User wrote:
>> Why do people keep responding to his efforts?
>
> Well, maybe (just maybe) because what I do is not
> wrong.
jacob, I see that "rose...@mailinator.com" has posted a followup.
This person is nothing more than a troll; he certainly does not
represent anyone else on this newsgroup. I encourage you to ignore him.
Kenny McCormack
>jacob navia wrote:
>> Default User wrote:
>[...]
>>> Why do people keep responding to his efforts?
>>
>> Well, maybe (just maybe) because what I do is not
>> wrong.
>[...]
>
>jacob, I see that "rose...@mailinator.com" has posted a followup.
>This person is nothing more than a troll; he certainly does not
>represent anyone else on this newsgroup. I encourage you to ignore him.
I think he speaks quite eloquently for most of the regulars here.
Mark McIntyre
Coming from a famous troll, thats amusing.
(gad I hate changing newsclients,you have to retrain everything...)
Kenny McCormack
Amusing? Yes. Entertaining? Of course. True? Definitely!
>(gad I hate changing newsclients,you have to retrain everything...)
Channelling Denny Hastert?
CBFalconer
>
... snip ...
> My paraphrasal:
> Threads are hard to understand. Only smart people should program
> with threads.
>
> My rebuttal:
> I write threaded code every day (basically, everything I write
> runs in threaded environments), so it can't be that difficult.
> Threads consume less resources than processes. Furthermore, the
> new wave of horsepower seems to be derived from multiple CPUs and
> multiple cores on the CPUs.
Between 30 and 40 years ago Per Brinch Hansen used the monitor
concept to write concurrent systems. They worked, and were simple
to understand.
--
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
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.
CBFalconer
> jacob navia wrote:
>
... snip ...
>>
>> 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.)
Definitely not sneering. That requires the appropriate lip curl,
and I see no sign whatsoever of that.
CBFalconer
>
... snip ...
>
> 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?
J. J. Farrell
> Peter Nilsson wrote:
>> jacob navia <ja...@nospam.com> wrote:
>>> We had another thread discussing the criticisms to C
>>> addressed those criticisms besides the usual "nonsense"
>>> and similar contributions.
>>
>>
>> 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.
>
> 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 can never work out whether you are a fantasist or simply a liar. Your
claims about what was said in that thread are untrue.
Ian Collins
> On Thu, 15 Nov 2007 20:52:18 +0100, jacob navia
> <ja...@nospam.com> 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.
>
busy?
--
Ian Collins.
Richard Harter
Well, you can always sign up with the Seti project or one of
those prime buster projects.
jacob navia
Yes.
Parallel data structures, specially tables.
Tables are inherently parallel. They can be treated in parallel without
any need for synchronization if each parallel processing "thread"
works with a specific part of the table.
And I put "thread" in quotes because there is no modification of the
global variables and all the associated problems.
Ian Collins
> Ian Collins wrote:
>> You have a better way for a single application to keep all of your cores
>> busy?
>>
>
> Yes.
>
> Parallel data structures, specially tables.
>
> Tables are inherently parallel. They can be treated in parallel without
> any need for synchronization if each parallel processing "thread"
> works with a specific part of the table.
>
References?
I'd be interested in seeing an implementation for a mainstream platform
that doesn't use threads under the hood.
--
Ian Collins.
jacob navia
Of course under the hood will be parallel cpus doing paralell execution!
What I want to do is described at best in
SIMD Programming Manual for linux and windows
by Paul Cockshott and Keneth Renfrew
Springer editor. ISBN 185233794X
Year: 2004.
This is a parallel tables implementation of pascal. It
implements most ideas of APL (A Programming Language) from Iverson.
Ian Collins
> Ian Collins wrote:
>> jacob navia wrote:
>>> Ian Collins wrote:
>>
>>>> You have a better way for a single application to keep all of your
>>>> cores
>>>> busy?
>>>>
>>> Yes.
>>>
>>> Parallel data structures, specially tables.
>>>
>>> Tables are inherently parallel. They can be treated in parallel without
>>> any need for synchronization if each parallel processing "thread"
>>> works with a specific part of the table.
>>>
>> References?
>>
>> I'd be interested in seeing an implementation for a mainstream platform
>> that doesn't use threads under the hood.
>>
>
> Of course under the hood will be parallel cpus doing paralell execution!
So threads aren't bad after all.
--
Ian Collins.
jacob navia
No. Threads as used commonly in C and C++ leave the complexity
of managing a global context in parallel to the programmer. He/she
has to figure out all the synchronization, randezvous, etc etc
needed to keep sanity. This is just impossible and will result always
in systems that have synchronization bugs.
It is just not scalable, because people can't be perfect at all times,
and this is a constant in my argumentation here. You can have a good
programmer that will be good most of the time. You will have a
bad programmer that will be good only sometimes. But NOBODY will
be perfect, and that is what is required: perfection.
It is a similar discussion as the malloc/free discussion. You can get
away with it when the system is small, but in a BIG system you are bound
to make a mistake.
Ian Collins
doesn't require synchronisation and there are others.
> It is just not scalable, because people can't be perfect at all times,
> and this is a constant in my argumentation here. You can have a good
> programmer that will be good most of the time. You will have a
> bad programmer that will be good only sometimes. But NOBODY will
> be perfect, and that is what is required: perfection.
>
> It is a similar discussion as the malloc/free discussion. You can get
> away with it when the system is small, but in a BIG system you are bound
> to make a mistake.
>
So how do modern operating systems scale over multiple cores? They tend
to be big systems and they depend on threads.
--
Ian Collins.
user923005
With modern systems, the slowdowns as the problem scales in size have
little do to with threading and much to do with semaphores and mutexes
(traditional locking schemes).
A solution that scales better than lock based exclusion is software
transactions:
http://en.wikipedia.org/wiki/Software_transactional_memory
There is an experimental C compiler that performs software
transactions:
http://softwarecommunity.intel.com/articles/eng/1460.htm
There are also kits on sourceforge to accomplish similar goals.
Here is one example:
http://softwarecommunity.intel.com/articles/eng/1460.htm
The paper at the above site is a good read.
Ian Collins
> On Nov 19, 3:28 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> So how do modern operating systems scale over multiple cores? They tend
>> to be big systems and they depend on threads.
>
> With modern systems, the slowdowns as the problem scales in size have
> little do to with threading and much to do with semaphores and mutexes
> (traditional locking schemes).
All true, but a decent OS will scale to hundreds of cores.
Don't forget my original post was a response to "since threads are a
mistake".
--
Ian Collins.
Charlie Gordon
da5a9ca5-07a8-481a...@f3g2000hsg.googlegroups.com...
>
<trash snipped by AGC>
>
> If I were you, I'd go and see a psychiatrist. Oh, and go learn
> something about C while you're at it.
Plus con, tu meurs.
--
Chqrlie.