Discussing the criticisms

Discussion in 'C Programming' started by jacob navia, Nov 15, 2007.

  1. jacob navia

    jacob navia Guest

    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
    jacob navia, Nov 15, 2007
    #1
    1. Advertising

  2. jacob navia

    CBFalconer Guest

    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
    CBFalconer, Nov 15, 2007
    #2
    1. Advertising

  3. jacob navia

    CBFalconer Guest

    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
    CBFalconer, Nov 15, 2007
    #3
  4. jacob navia

    Ian Collins Guest

    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.
    Ian Collins, Nov 15, 2007
    #4
  5. jacob navia

    jacob navia Guest

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


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Nov 15, 2007
    #5
  6. On Thu, 15 Nov 2007 20:52:18 +0100, jacob navia
    <> 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.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,
    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
    Richard Harter, Nov 15, 2007
    #6
  7. jacob navia

    user923005 Guest

    On Nov 15, 12:27 pm, (Richard Harter) wrote:
    > On Thu, 15 Nov 2007 20:52:18 +0100, jacob navia
    >
    > <> 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.sunlabs.com/~ouster
    > >1996 USENIX Technical Conference
    > >(January 25, 1996)
    > >(2)


    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, ://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.
    user923005, Nov 15, 2007
    #7
  8. 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
    Mark McIntyre, Nov 15, 2007
    #8
  9. jacob navia <> 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
    Peter Nilsson, Nov 15, 2007
    #9
  10. jacob navia

    jacob navia Guest

    Peter Nilsson wrote:
    > jacob navia <> 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
    jacob navia, Nov 15, 2007
    #10
  11. 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.

    --
    Keith Thompson (The_Other_Keith) <>
    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"
    Keith Thompson, Nov 16, 2007
    #11
  12. jacob navia

    Richard Bos Guest

    jacob navia <> 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 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
    Richard Bos, Nov 16, 2007
    #12
  13. On 15 Nov, 20:27, (Richard Harter) wrote:
    > On Thu, 15 Nov 2007 20:52:18 +0100, jacob navia
    > <> 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
    > >
    > >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
    Nick Keighley, Nov 16, 2007
    #13
  14. jacob navia wrote:
    > Peter Nilsson wrote:
    >> jacob navia <> 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.

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


    Let he who is without sin cast the first stone.

    --
    Philip Potter pgp <at> doc.ic.ac.uk
    Philip Potter, Nov 16, 2007
    #14
  15. On Nov 15, 4:11 pm, jacob navia <> 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.
    >
    > 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.
    Spiros Bousbouras, Nov 16, 2007
    #15
  16. jacob navia

    Eric Sosman Guest

    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.

    --
    Eric Sosman, Nov 16, 2007
    #16
  17. jacob navia

    jacob navia Guest

    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.

    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.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Nov 16, 2007
    #17
  18. On Fri, 16 Nov 2007 02:25:40 -0800 (PST), Nick Keighley
    <> wrote:

    >On 15 Nov, 20:27, (Richard Harter) wrote:
    >> On Thu, 15 Nov 2007 20:52:18 +0100, jacob navia
    >> <> 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
    >> >
    >> >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


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


    Richard Harter,
    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
    Richard Harter, Nov 16, 2007
    #18
  19. jacob navia

    Eric Sosman Guest

    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.

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

    --
    Eric Sosman, Nov 16, 2007
    #19
  20. jacob navia

    Richard Guest

    Eric Sosman <> writes:

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


    Agreed. They should try to remain open minded before doing the
    habitual closing of ranks.
    Richard, Nov 16, 2007
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. VisionSet

    JUnit et al approach - criticisms

    VisionSet, Nov 27, 2005, in forum: Java
    Replies:
    65
    Views:
    1,449
    Timbo
    Dec 20, 2005
  2. Sarath
    Replies:
    5
    Views:
    293
    Kai-Uwe Bux
    Feb 22, 2007
  3. Replies:
    2
    Views:
    257
  4. Hal Fulton

    While we're discussing 'ri'...

    Hal Fulton, Jul 8, 2004, in forum: Ruby
    Replies:
    16
    Views:
    152
    Charles Comstock
    Jul 9, 2004
  5. betatwelve

    after discussing about the line

    betatwelve, Mar 28, 2013, in forum: Python
    Replies:
    0
    Views:
    83
    betatwelve
    Mar 28, 2013
Loading...

Share This Page