Endless arguing

M

Morris Keesan

Quoting someone on a BBC radio programme from a few weeks ago:

-"Remember, if you choose to argue with an idiot, the best possible
outcome is that you've won an argument with an idiot."-
 
J

James Harris

Quoting someone on a BBC radio programme from a few weeks ago:

-"Remember, if you choose to argue with an idiot, the best possible  
outcome is that you've won an argument with an idiot."-

There's some truth in the quote but there are other factors to
consider.

For example, if none of the careful deceits and misrepresentations are
challenged someone reading the words - either now or at some time in
the future - may believe them to be true.

James
 
O

osmium

James said:
There's some truth in the quote but there are other factors to
consider.

For example, if none of the careful deceits and misrepresentations are
challenged someone reading the words - either now or at some time in
the future - may believe them to be true.

No single human could possibly have any effect on the amount of faulty
information that exists. You might as well decide to stop the ocean tides.
 
A

Army1987

No single human could possibly have any effect on the amount of faulty
information that exists. You might as well decide to stop the ocean
tides.

It is possible to clean all the streets in Paris in one quarter of an
hour: all that is needed is for everybody to clean the street they live
in.
 
S

stan

James said:
There's some truth in the quote but there are other factors to
consider.

For example, if none of the careful deceits and misrepresentations are
challenged someone reading the words - either now or at some time in
the future - may believe them to be true.

Do you honestly think that can justify the S/N here?
 
T

Tim Streater

Army1987 said:
It is possible to clean all the streets in Paris in one quarter of an
hour: all that is needed is for everybody to clean the street they live
in.

Sure. But if everyone else does it, and I don't, then I have an almost
entirely clean city at no cost to me. So if I'm selfish, where's my
incentive?
 
K

Kenny McCormack

Do you honestly think that can justify the S/N here?

Right or wrong, that *is* the justification given for why the "regs"
can't resist talking to the "trolls". In fact, that's the basic reason
why we "trolls" post in the first place - because we can't stand to see
the nonsense that the "regs" post go unchallenged.

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...
 
S

Seebs

No single human could possibly have any effect on the amount of faulty
information that exists. You might as well decide to stop the ocean tides.

Is that true? You should check snopes.

-s
 
J

jameskuyper

Army1987 said:
It is possible to clean all the streets in Paris in one quarter of an
hour: all that is needed is for everybody to clean the street they live
in.

That's a bad analogy. Responding to a troll does not remove the
garbage he's already produced; it's more closely analogous to putting
up a flag next to the garbage, warning people of it's presence.
Furthermore, that "flag" has a nasty side-effect: it encourages the
troll to produce more garbage.

Fixing up your analogy to match this reality would involve having the
people of Paris act like idiots (and I'm not trying to suggest that
they are): instead of removing the garbage, each one would have to put
out a piece of food next to each piece of garbage they found on their
own street - to warn people that there's a piece of garbage there.
Various animals would come by to eat the food, adding their own fresh
contribution to the garbage. The citizens of Paris would put out more
food to mark the fresh garbage, etc... How quickly would the streets
of Paris be cleaned up by that approach?

Trying to combat trolls by pointing out their errors may not seem as
stupid as the above behavior. However, it's equally counterproductive,
and the "end" results are of comparable quality.
 
J

jacob navia

Morris Keesan a écrit :
Quoting someone on a BBC radio programme from a few weeks ago:

-"Remember, if you choose to argue with an idiot, the best possible
outcome is that you've won an argument with an idiot."-
Well, there were around 270 messages in the first thread about Schildt's
book, and there are several hundreds in the following messages.

When I posted a request about allocators for the container library, I
received 2 answers.

Yes, TWO, much less than the guy that asked the answer of 0.5*0.5. This
shows the priorities of people here. Most of them aren't able to follow
a technical discussion or have no interest in technical discussions, the
C language or whatever. Their only interest is showing off, inflating
their (already bloated) egos, and similar nonsense.

jacob
 
S

Seebs

When I posted a request about allocators for the container library, I
received 2 answers.

I don't know about the recent one, but I know I've responded to previous
questions on that topic.

It's not a topic I am hugely invested in, just because I don't think a
container library is a good fit for the way I've usually seen C used, but
I think it's interesting, and I have certainly made suggestions about it.

Fundamentally, though, you're working on something that most of the people
here don't think they need, and you aren't saying things which are hilariously
over the top and obviously wrong. When you do say things which are obviously
wrong, you get more responses, but they're all corrections.

I suspect some of what you're seeing is inertia of various forms; most of us
already have or don't need a list library, for instance. I quite simply
can't comprehend when I'd end up wanting a "container". I can see when I
want lists, or when I want arrays, but I can't conceive of ever writing a
piece of code in which I want a container but don't care which of those it
is, or in which my choice of list or array would change. As a result, I
simply don't see "container" as a useful abstraction for writing code.

A similar design for, say, a hash library, which was unambiguously a library
for hashes and not for any other sort of thing, might be very interesting
to me, because I've not been especially happy with the hash libraries I've
seen.

-s
 
O

osmium

Richard said:
Do you honestly think the S/N ratio will improve if the noisemakers go
unchallenged?

No question at all about it, yes. Spinoza can make, maybe five posts a day,
but attracts responses like a turd in the middle of the street attracts
crows. Look at the Spinoza threads and see how many are made by him and how
many are made by others.
 
D

Default User

stan said:
James Harris wrote:

Do you honestly think that can justify the S/N here?

I agree. You can't beat trolls by arguing. The only way is to completely
freeze them out.



Brian
 
S

Seebs

No question at all about it, yes. Spinoza can make, maybe five posts a day,
but attracts responses like a turd in the middle of the street attracts
crows. Look at the Spinoza threads and see how many are made by him and how
many are made by others.

I think he makes way more than five a day. But yes, he does tend to end up
with more responses than his original posts. And yes, I would agree that
at this point, "challenging" the noisemakers isn't doing anything.

Step 1: Killfile Nilges.
Step 2: Encourage other people to do so.
Step 3: Try to keep responses to anything in his threads strictly topical.
Step 4: ???
Step 5: Profit!

-s
 
K

Keith Thompson

Richard Heathfield said:
Do you honestly think the S/N ratio will improve if the noisemakers go
unchallenged?

YES!

The vast majority of Nilges' posts are responses to responses to his
earlier posts. Attempts to address his technical errors, even while
ignoring his crap, result in more of his crap.

I don't know whether he would stop posting if everyone ignored him,
but I suspect his volume would drop considerably, and what we're doing
now certainly isn't working.
 
S

Seebs

The vast majority of Nilges' posts are responses to responses to his
earlier posts. Attempts to address his technical errors, even while
ignoring his crap, result in more of his crap.

Yes. Perhaps more importantly, they almost never result even in
*improved* crap. It's not as if he's improving.
I don't know whether he would stop posting if everyone ignored him,
but I suspect his volume would drop considerably, and what we're doing
now certainly isn't working.

Usually, they escalate further and further to try to continue to
elicit narcissistic supply (responses, especially responses which
appear to imply that he's got some kind of point or qualification),
and eventually melt down completely and go do something else.

Oddly, critics are nearly as good a response as praise. They at
least imply that he's really participating and shaping outcomes.

-s
 
E

Ersek, Laszlo

I suspect some of what you're seeing is inertia of various forms; most
of us already have or don't need a list library, for instance. I quite
simply can't comprehend when I'd end up wanting a "container". I can
see when I want lists, or when I want arrays, but I can't conceive of
ever writing a piece of code in which I want a container but don't care
which of those it is, or in which my choice of list or array would
change. As a result, I simply don't see "container" as a useful
abstraction for writing code.

I concur. Grouping containers by space and time efficiency seems useful,
but only for supporting the programmer in choosing one. Abstracting an
interface from container "backends" that are replaceable between
"performance classes" seems leaky (or, in the other direction,
inflexible).

Looking back:

From: (e-mail address removed) (Ersek, Laszlo)
Subject: Re: Idioms for iterators in C
Date: 28 Jan 2010 20:57:50 +0100
Message-ID: said:
[...] With the exception of foo_close() and foo_delete(), all foo_*()
operations should try not to invalidate any existing iterator.
foo_delete() should take an iterator and try not to invalidate any
iterator pointing elsewhere. [...]

From: Eric Sosman <[email protected]>
Subject: Re: Idioms for iterators in C
Date: Thu, 28 Jan 2010 18:06:09 -0500
Message-ID: said:
Three points: First, concrete iterator objects are by no means
original with me. Second, I think you'll find it difficult to make an
iterator behave sensibly if the container is modified while an iteration
is in progress (think of a hash table that gets re-hashed when an
insertion makes it too crowded). Third (and most important), there are
only two S'es in "Sosman."

If I ever intended to unify iterator interfaces at all, that was about the
end of it. As soon as I wanted to bolt something "really useful" on an
iterator interface, it was immediately shown to be container specific. I
took it as proof that my pursuit is futile.

lacos
 
J

jacob navia

Ersek, Laszlo a écrit :
If I ever intended to unify iterator interfaces at all, that was about
the end of it. As soon as I wanted to bolt something "really useful" on
an iterator interface, it was immediately shown to be container
specific. I took it as proof that my pursuit is futile.


I have found the solution.

There is the "Iterator" object with 3 fields:

GetNext
GetPrevious
GetFirst

This 3 function pointers yield a pointer to each stored object,
or NULL when there are none.

Now, newIterator(container) builds a *container specific* structure
with the "iterator" structure at the start. Then, it returns a pointer
to the start. Get next receives this iterator specific structure
and is iterator specific without the user seeing it.

This way I have the best of both worlds: container specific code
AND generic interface for the user:

Iterator *it = newIterator(list_container);

it is a pointer to the first part of the list iterator. The list
iterator has many other fields that the user doesn't see. When you call
void *obj = it->GetFirst(it);

The it->GetFirst() routine is a list container specific routine that
looks into the hidden fields of "iterator" and does its tricks!

This works like a charm.

I solved your problem. Now, it would be nice if you worked with me
and we could develop this together. I can't do everything alone.

Thanks for your contribution

:)
 
S

Seebs

There is the "Iterator" object with 3 fields:

Hmm.

This 3 function pointers yield a pointer to each stored object,
or NULL when there are none.
Okay.

Now, newIterator(container) builds a *container specific* structure
with the "iterator" structure at the start. Then, it returns a pointer
to the start. Get next receives this iterator specific structure
and is iterator specific without the user seeing it.

Seems reasonable.
I solved your problem. Now, it would be nice if you worked with me
and we could develop this together. I can't do everything alone.

An obvious issue suggests itself. One of the most useful containers is
the "hash" -- that's sort of a perlism as a name, but basically, an
associative array in which each member has a key, but keys are not necessarily
a numerically-ordered list.

So, if I call GetFirst() on such a thing, how/where do I find out what key
is associated with the first item?

Another thing to consider: Trees. Do you want to have something like
Iterator *it = GetIterator(tree, ITERATE_DEPTH_FIRST);
or what? (It is not necessarily an attribute of the tree itself whether
you want to iterate over it depth-first or breadth-first!)

-s
 
I

Ian Collins

Morris Keesan a écrit :
Well, there were around 270 messages in the first thread about Schildt's
book, and there are several hundreds in the following messages.

When I posted a request about allocators for the container library, I
received 2 answers.

But you only replied to one, so the debate never got going.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top