what is encapsulation in an interface ?

[Mike Schilling]

If the canned stuff were powerful enough to be of really general use (so
that, in fact, there was very rarely a reason to write "raw" loops -- as
is the case with the Smalltalk collections hierarchy for instance), then
the canned stuff, /because/ it's idiomatic, becomes the clearer option.
But for that to happen, the canned stuff has to be a lot more expressive
than that provided by java.util.Collection: I'm still trying to think of a
valid reason for such a very special-purpose routine as
java.util.Collection.frequency() to exist at all. Now if there were a way
to say "for instances of X in this collection do [... such and such ...]",
then Ken's original example would be made clearer than either of the
options that are actually available. Something like (invented crap
syntax):
int count = 0;
for (Object o: list: {o == null})
count++;
which retains the possibility of efficient implementation, clearly
expresses what we are trying to do, and doesn't depend on some extremely
specialised (absurdly over-specialised, IMO) routine happening to exist.

As has been pointed out, you can do this sort of thing in C#. You could
build it in Java too, but since the expression would have to be specified as
a method in an anonymous class. it would amount to obfuscation, the result
being something like

count = Collections.getFilteredCollection(list, new Filter()
{
@Override
public boolean accept(Object member)
{
return member == null;
}
}).size();

 

[Lew]

I'm not promoting "ignorance of the API"; I'm promoting avoiding the less
well-known corners of it when the alternative isn't significantly long
and convoluted (so, likely to contain bugs, harder to read for intent,
etc.). There is a cost to the maintenance programmer in parsing a short
for loop; there's also a cost to looking up an infrequently-encountered
library function in the API documentation.

In other words, you're promoting ignorance of the collections API.

Pitiful. Go thou and study it!

I'm not saying one must use that method, but I am saying that one must be
aware of it in order to collect pay as a Java programmer.

Also, I work with the API docs open anyway when I write Java code. Don't you?

Would you contend that my eschewing gratuitously imbuing my vernacular
with a vast and varied assortment of obscure, peculiar, and infrequently-
encountered polysyllabic utterances, including multifarious terms of
Greco-Latin etymology, in the interests of committing to this electronic
medium more lucid, concise English prose that will be comprehended with
less difficulty and more alacrity "promoting ignorance of the English
language"?

I contend that that paragraph is completely clear and completely irrelevant.
We are talking about a professional skill for which people claim payment, and
there's a professional standard to apply in that case. Your example has no
such consideration. Were the person in question paid as a grammarian or copy
editor, I would expect them to have at least as little difficulty with that
paragraph as I did.

Let me ask you, did you look up those words to write that paragraph or did you
write that "closed book"?

Occasionally such a word (or API function) makes things *much* shorter
and simpler. This wasn't one of those occasions.

Because of the simplicity of the example. Real-world examples can be (and in
the case of the one I cited, was) more complex.

You seem to think that I am espousing the exclusive use of API calls where
possible to eliminate 'for' loops. That would be a mischaracterization of my
point. I'm saying that /in general/ it's wise to use API calls because they
reduce risk compared to re-inventing their logic. That doesn't mean /always/.
In this profession one must *think*. The dogmatic insistence that the loop
is correct or more clear because it's "obvious" in some restricted use case is
not appropriate.

Lew wrote"

Other than that, the discussion seems to be a matter of style. It is
certainly plausible that the library method would have better
performance than the hand-written 'for' loop, as the java[x].* APIs have
the benefit of close cooperation with the JVM implementation, so an
argument based on performance is a no-go.

I don't agree. It's very unlikely that Collections.frequency is anything
other than an ordinary Java method that gets no special help from the

It's "very unlikely"? Have you checked? Why not?

Where do you get these assertions of probability, anyway? What's your
statistical evidence, hm?

"Likely" or "unlikely" is a boneheaded assessment to make when a few minutes
will determine the answer with certainty. I didn't look it up because it
doesn't matter. In another post, which certainly you must have read, I
pointed out that, worst case, the method wraps the same or equivalent 'for'
loop, from which we can reason that it's unlikely there's much if any
advantage to either idiom compared to the other.

Now to settle it, I will be the bigger man and look it up for you. You're
welcome.

.... ... ... ...

Yep, it's a "tight for loop". Performance difference - negligible and could
go either way.

Next time, instead of making foolish "very unlikely" statistical assertions,
check the facts.

implementation. It is certainly unlikely to be native (and if it was, JNI
call overhead would probably make it SLOWER for all but the largest
collections).

It's so unlikely to be a native call that it isn't one. Probability zero.
You're welcome again.

If that is your opinion, why have you entered this debate at all?

Why have you?

It would seem that there are Java novices and even non-novices that have
long since familiarized themselves with the "for" loop and know much of
the collections API but have never heard of, specifically,
Collections.frequency.

Any self-described Java programmer who isn't aware of at least the possibility
of such a method should switch to a profession whose hardest task is cleaning
off the floor mats at the end of their shift.

Once again you promote ignorance of the API, while uttering mealy-mouthed
denials that that's what you're doing.

Why are you so opposed to a professional being skilled in the fundamental
skills of their profession?

The Collections class alone has fifty methods in it. Are you honestly
expecting everyone to have the whole thing thoroughly memorized? And what
other parts of the API, besides?

Is that what I said? I think not, and if you go back to what I actually said,
I stand by it. If you put up straw-man arguments and knock them down, what
have you won?

Here's what I actually said, and how weird that you can quote it and still
misrepresent it. Did you think no one would notice?

Well, this does seem to be a day for unfounded, exaggerated accusations,
doesn't it!

I put the foundation for it in the statement itself. Did you miss it? You
must have. It's not a long sentence; read it again.

And it's not exaggerated. Professionals have a fiduciary responsibility to
keep their skills up to date. Not to do so causes harm, and because the
failure to hone skills is deliberate, that constitutes sabotage of the
affected projects. Such a person is a bounder for being so unethical.
They're a poseur because they represent themselves as professionals without
evincing professional behavior. They're a thief because they collect money
dishonestly.

Thus my claim is both well-founded and not exaggerated.

It's also not an accusation. At least, not unless you found that the shoe
fit, in which case you just accused yourself. Do you /at least/ work to keep
up to date /at least/ with the collections API?

Perhaps you, too, could stand to get a good night's rest before
contributing to this thread again.

Perhaps you, too, could try addressing the points instead of making stupid
rhetorical remarks.

Or maybe you have evidence. How much sleep have I gotten? How much would
constitute "a good night's rest"?

What's the matter, cat got your tongue?

If you can find and demonstrate a bug in the loop I posted, I'll concede
this point, otherwise not.

Once again, for the thick of skull, let me repeat that I speak of general
priniciples. Didn't you see the word "generally" in my statement? You did?
What did you think it meant?

And I could care less if you, personally, concede this point. There are a lot
of folks reading this thread who will get to see the logic and truth, and it
is to them I make these statements. You obviously care little for
professional training and standards. I just don't want that attitude to
infect anyone else.

Obviously retainAll is more complex, since it must check each item
against a whole list of items to keep and not just one. Though it seems
there's a clear and quick implementation in terms of the from-Collection
Set constructor and the contains method:

Set s2 = new HashSet(c);
for (i = s.iterator(); i.hasNext()
if (!(s2.contains(i.next()))) i.remove();

Where are your generics?

You have managed to recapitulate pretty much the exact code of the library
method, without the feature of recording whether there actually was a change.
Congratulations, through carefully maintained ignorance of the API you've
managed to re-invent a buggy and less capable version of that particular wheel
that uses more collection objects than the API version already provided.
Plus, if 'c' is not a 'Set' you just destroyed the invariants of that
collection.

You've made my point there. So many flaws in so few lines of code. Just use
the API for God's sake!

(That needs to make a temporary collection as large as the number of
distinct elements in c, so its space complexity is O(c.size()), but its
time complexity is only O(c.size() + s.size()). It also requires the

Exactly. Yet somehow the API call doesn't do that. Hmm.

elements of c and s properly implement hashCode, though that's pretty

In other words, it requires correctly coded elements. Now there's an insight.

You do know that HashSet needs that anyway, right?

typical anyway. (When was the last time you saw retainAll called on a
TreeSet whose elements' hashCode was no good and awful?) The low-space-
complexity version has a nested second loop and O(c.size() * s.size())
time complexity.)

Lew wrote

That's a straw man argument. Nobody said for loops were equivalently
reliable; just that one-liner ones are surely not MUCH less reliable (and
easily fixed quickly if a problem DOES arise).

I was speaking in general terms, as you would have known had you not chosen to
ignore every time I said so. Ergo my statement was not a straw-man argument,
and your attempt to mischaracterize it as such in order to avoid the point is
noted.

 

[Lew]

That, too, is a double edged sword. It also costs money to have a guy on
staff spend a larger amount of time reading the API documentation.

It costs even more to have a programmer on staff who spends too little time
reading and studying the API documentation.

But you go on witchyo bad self, promoting greater ignorance and lower
standards. Just don't try to get a job where I work, because I'll make sure
that the managers read this conversation.

 

[Arne Vajhøj]

That, too, is a double edged sword. It also costs money to have a guy on
staff spend a larger amount of time reading the API documentation.

It also cost to have him read about for loops.

But the usual expectation when you hire a Java developer is
that he already knows the Java language and how to quickly lookup
things in the Java API docs.

Sometimes that larger amount of time will pay dividends in saved time
elsewhere and later. Other times, not so much. And the less well known
and more situational the API being used, and the shorter the code using
it replaces, the more the balance tilts the other way.

On the one hand, the more situational the API and the shorter the code
using it replaces, the less time using it will save up front.

On the other hand, the less well known the API, the more that time spent
in the API documentation will get multiplied. The coder that uses the API
had to spend marginal added time in the documentation to know about and
use it. Then, if it's infrequently encountered, it's much more likely the
maintenance programmers will, each time they examine the parts of the
code that use it, need to look it up again rather than remember what it
does. This, of course, increases even further if the API method or class
involved is not ideally-named to make its behavior and purpose crystal-
clear.

Lots of words to say that you disagree with most things
invented in software development within the last 40 years or so.

Reusing code by using an existing library should not be
avoided due to the cost of reading the docs.

And it should not take much time. A Java developer that does
not know how to find stuff in the Java API docs is a problem
that need to be solved - not by changing the reusability strategy
for the project, but by increasing the developers skills.

Arne

 

[Arne Vajhøj]

I'm not promoting "ignorance of the API"; I'm promoting avoiding the less
well-known corners of it when the alternative isn't significantly long
and convoluted (so, likely to contain bugs, harder to read for intent,
etc.). There is a cost to the maintenance programmer in parsing a short
for loop; there's also a cost to looking up an infrequently-encountered
library function in the API documentation.

Avoiding the less used corners does not make much sense.

Why do you think it was added? My guess is that it was not because
the expectation is that developers would not use it because it
is not much used.

And besides the expected usage of the Java API (and other modern API's)
is not to learn everything, but instead to learn how to quickly find
things in the docs.

And your maintenance programmer should consider using an IDE, so
he can move the cursor over the method and read the Java docs
from that.

If you can find and demonstrate a bug in the loop I posted, I'll concede
this point, otherwise not.

Bullshit.

If I can post a correct piece of assembler code does that
make writing in assembler as safe as writing in Java?

No!

Arne

 

[Arne Vajhøj]

[ SNIP ]

Other than that, the discussion seems to be a matter of style. It is
certainly plausible that the library method would have better
performance than the hand-written 'for' loop, as the java[x].* APIs have
the benefit of close cooperation with the JVM implementation, so an
argument based on performance is a no-go.

I don't agree. It's very unlikely that Collections.frequency is anything
other than an ordinary Java method that gets no special help from the
implementation. It is certainly unlikely to be native (and if it was, JNI
call overhead would probably make it SLOWER for all but the largest
collections).

[ SNIP ]

I'm basically neutral in this discussion so far, but I have to agree
with you (Ken) insofar as I disagree with the blanket statement that
"java[x].* APIs have the benefit of close cooperation with the JVM
implementation".

"Close cooperation"? And hence implicitly better performance? I don't
get that at all. Moving on from Ken's observations, and looking at
_human_ cooperation, I have strong doubts that just because a developer
working on the Collections API is more strongly related, officially, to
a JVM developer, than a third-party programmer, that we're typically and
commonly getting tighter, faster, more reliable code because of it.

I think the benefits to be had are those that you'd expect from any
library that gets used enough. Lots of eyeballs, lots of testing.
Period. There's nothing intrinsically special about the java[x] APIs -
Sun (and now Oracle) didn't/doesn't employ all Josh Bloch's to write
that stuff. In no few cases the java[x] API designs are mediocre, and
always have been - it's not all superstars writing this code.

That is correct.

But there should be a decent chance that the worst catastrophes
get fixed more quickly in a commonly used library than in a projects
reimplementing Java API functionality code.

Even though I am still waiting for String replace to get
enhanced.

Arne

 

[Arne Vajhøj]

04 PM, Ken Wesson wrote:
[...]
really simplifies and enhances coding power and expressiveness.

I think my for loop is a bit clearer (and probably runs quite a bit
faster) than Tom's code.

Why is it clearer?

You need less detailed knowledge of the API library to know what it
means, for one thing.

If writing your own code instead of using a standard API is a good thing
in general

Nobody claimed that "in general".

True. But there were no indication that it was special case either.

As was noted in Arved's reply to your post, it usually means something
somewhat different from what Collections.frequency actually does.

Not more different than what can be deducted from the context.

What if it's quite small but there are a lot of them?

You can easily create an artificial test where it matters.

But in a real world program?

It most likely does not matter for overall performance.

Unless you have a special case and have tested it to be a
problem, then you should assume it not to be a problem.

Arne

 

[Arne Vajhøj]

Hmm.. If something is too slow already (and that's not exactly a rare scenario
in computing -- nearly everything I ask a computer to do, I have to wait longer
than I want for it to complete), then taking twice as long is twice as bad
(more or less).

Most people know that feeling.



But the cure is very rarely to reduce the time for all modules
with 50%.

Usually it is reducing the time for the module that is the
bottleneck with 55%.

But I think the real relevance of performance considerations here is that
"canned" operations such as those in Collections have the potential (not
realized in this particular case, as it happens) to be faster than hand-written
loops. For instance a Bag should be able to tell you how many instances of X
it contains a lot faster than most flavours of List.

If you do it the SUN/Oracle/Java way, then any good ideas they
get will benefit you when you change implementation or upgrade
Java.

Arne

 

[Arne Vajhøj]

Constant factors can matter. Even an *added* overhead can matter if the
whole shebang is done in a larger loop that has many iterations.

And that is the only thing happening in the app.

Which makes it very rare.

In the original post that raised this sorry debate, the code in question
was proffered as an "obvious implementation" for a method called
countNonNulls. Obviously, making such a method and then calling it from
elsewhere shows intent and hides implementation.

That is a bullshit argument.

Because you could claim that any code hides implementation, because
the code is in a method that gets called from somewhere.

The implementation is not hidden in this method with the
explicit for loop - it is hidden with the API call.

Arne

 

[Lew]

We can do that, in the very next loop you posted after making this arrogant
claim. That's enough to earn that concession you promised.

And why the disingenuous smileys, hm?

Bullshit.

If I can post a correct piece of assembler code does that
make writing in assembler as safe as writing in Java?

No!

Not only that, but he posted another equally short loop that had several
flaws, to whit, not returning the same value as the lib method, not using
generics, not conserving memory in the same way (and not documenting the
unusual memory requirement), all in just a few lines of a so-called "tight
'for' loop". So the same poster who challenged us to find a flaw in one short
loop as if that invalidated the general argument, demonstrated the flaws of
his espoused approach in the very next short loop he posted. So by his own
example he proved the general point we are making, that using the API library
is safer than re-inventing functionality.

Thanks, Kenny boy!

 

[Lew]

Of course, you have since dropped several more similarly-unpleasant posts
into this newsgroup, and because you did so I took the liberty of
googling your past posting-history. It seems you are in fact something of
a prick.

I was going to answer you seriously, but you keep failing to answer the actual
points made, misrepresenting my points to "refute" them, and now this.

Plonk.

And yes, that is an insult. And an accusation.

But you have a consistent behavior pattern of nastiness towards anyone

Look who's talking.

that you feel, in your ever-so-arrogant opinion, is shirking what you

Projection.

Etc.

You, sir, without a valid point to make, instead completely derailed the
meritorious conversation with your low-brow personal retaliation.

Good work, Kenny boy.

 

[Lew]

So you claim. But I asked you to find one in the *same* loop. You know,

Thus restricting the conversation to a point I was not addressing. Why would
I respond to that? Just because you refuse to engage in what I'm saying
doesn't mean that what I said was invalid.

the little 59-character molehill you guys have made such a mountain out
of. After all it was only loops that small and clear that I was
suggesting using in lieu of obscure API calls that are nearly as long.

Yet another, pretty much equally short loop had bugs, thus proving the general
point that I was making.

Contrary to your claim upthread, I never said the 'for' loop was a bad idea,
only that one should be aware of the API and that it provides useful
alternatives - generally. I said that - generally - the API reduces risk
compared to hand-rolling, say, a "tight for loop". You proved that with your
own for loop. You keep distorting this point as though it were an attempt to
refute your claim that one trivial for loop was acceptable; it is not. Stop
intentionally twisting what someone else says in some misguided attempt to "win".

It stands that your second loop proved my general point, irrespective of your
trivial stand about one tiny loop that you miraculously didn't screw up. It
remains that your second loop beautifully illustrates my point, that
(generally speaking, just so you don't miss that point a sixth time) it's
risky to re-invent standard API calls. Thanks again.

As mentioned, I've plonked you already so your response is irrelevant. But
then, that won't be new.

Why is calling people liars (without evidence, natch) apparently the
official pastime of cljp regulars?

What? Who called anyone a liar? Or did your "unusually large vocabulary"
fail you? Hm?

What general argument do you claim I was trying to invalidate? I think
I've already explained (several times!) that my argument applied
specifically to short loops and similarly short snippets only, and was in

And yet your other "similarly short snippet" had more flaws than lines of code?

no way intended to be interpreted as a general advocacy for replacing ALL
API calls with roll-your-own functionality.

Nor was my statement an advocacy to replace all roll-your-own with API calls,
as you seem to misrepresent it.

Buh-bye.

 

[Tom Anderson]

Ahem:

return x.size() - Collections.frequency(x, null);

LOL j/k.

I do agree with Ken and Arved that 'frequency' is poorly named - it really
should be 'count'. It's not a disaster that it's called what it's called,
though.

tom

 

[Joshua Cranmer]

And if the API call is a little *less* easily understood, because it's a
"less used corner" and so requires a greater mental effort (or an actual
web search) for the reader to parse, then the balance starts tilting
noticeably in favor of the "for" loop.

I would like to point out that most modern IDEs can be set up to show
you the Javadoc of any method with 1 click or fewer.

 

[Arved Sandstrom]

[ SNIP ]

Other than that, the discussion seems to be a matter of style. It is
certainly plausible that the library method would have better
performance than the hand-written 'for' loop, as the java[x].* APIs
have
the benefit of close cooperation with the JVM implementation, so an
argument based on performance is a no-go.

I don't agree. It's very unlikely that Collections.frequency is anything
other than an ordinary Java method that gets no special help from the
implementation. It is certainly unlikely to be native (and if it was,
JNI
call overhead would probably make it SLOWER for all but the largest
collections).

[ SNIP ]

I'm basically neutral in this discussion so far, but I have to agree
with you (Ken) insofar as I disagree with the blanket statement that
"java[x].* APIs have the benefit of close cooperation with the JVM
implementation".

"Close cooperation"? And hence implicitly better performance? I don't
get that at all. Moving on from Ken's observations, and looking at
_human_ cooperation, I have strong doubts that just because a developer
working on the Collections API is more strongly related, officially, to
a JVM developer, than a third-party programmer, that we're typically and
commonly getting tighter, faster, more reliable code because of it.

I think the benefits to be had are those that you'd expect from any
library that gets used enough. Lots of eyeballs, lots of testing.
Period. There's nothing intrinsically special about the java[x] APIs -
Sun (and now Oracle) didn't/doesn't employ all Josh Bloch's to write
that stuff. In no few cases the java[x] API designs are mediocre, and
always have been - it's not all superstars writing this code.

That is correct.

But there should be a decent chance that the worst catastrophes
get fixed more quickly in a commonly used library than in a projects
reimplementing Java API functionality code.

Yes, which was my point in my first few sentences in my last quoted
paragraph above. Lots of traffic so hopefully quick action on defects or
performance or useability.

But that argument works better for non-trivial methods.
Collections.frequency _is_ trivial.

Even though I am still waiting for String replace to get
enhanced.

Arne

What enhancement is that?

AHS

 

[Arved Sandstrom]

LOL j/k.

I do agree with Ken and Arved that 'frequency' is poorly named - it
really should be 'count'. It's not a disaster that it's called what it's
called, though.

tom

No, it's not a disaster. Encountering its use in code, I'd look at the
context and the arguments and figure out what it does, probably checking
the API docs real quick to confirm that the writer meant "count".

However - and not with the Collections class specifically - bad naming
of this type might cause me to overlook a method if I were scanning
names in the top part of a class Javadoc. "frequency" in Collections I'd
probably catch (assuming that I was completely unfamiliar with that
class) as being really a "count" method. But I suspect I probably _have_
missed other API methods in the past simply because the authors couldn't
be arsed to give them a good name.

Arne points out that statisticians do use the term frequency for counts,
both absolute and relative. Point conceded. But how many developers are
familiar with statistics?

AHS

 

[Jerry Gerrone]

Now you're just being vulgar and rude.

That's Arnehole for you.

Is there nobody in this newsgroup capable of civilized debate? Every
disagreement however minor seems to nearly instantly occasion swear
words, name-calling, and even fairly serious accusations of intentionally
dishonest conduct. This group has a past history of some truly
thermonuclear flamewars and it's no wonder -- as near as I can tell most
of you are nearly as bad as [insult deleted]

No. None of the nasty things that you have said or implied about me
are at all true.

for turning every slightest disagreement into trench warfare in which
ground is given up but grudgingly and it's far preferable to curse,
evade, attack, or even point-blank accuse the other guy of some form of
treachery than to admit a mistake or misunderstanding of any kind.

That's classic cljp regular behavior, alright. I see that things
haven't changed in the years since my last post here. Let me guess,
newbies still get hazed mercilessly, too? And Lew, Arne, and Peter
Duniho are the main triad of evil, with occasional flamey
contributions by the rest of the usual suspects from way back when?

I see on reading the rest of this thread that you've already run afoul
of all three of those. That's what happens -- as soon as they find
anything in one of your posts (especially if it's a code snippet) that
they don't like, they start throwing subtle barbs and insults at you,
and if you speak up in your own defense, instead of maybe actually
accepting what you say, the bring out the bigger guns and flame you
more openly.

The one thing keeping this group from perpetual meltdown is that those of
you that are bad for that mostly agree with one another on most things.

Actually, that makes things worse. If they didn't do that, they'd
roast one another clean out of the newsgroup, or else learn to
actually tolerate dissenting viewpoints in their midst to avoid the
same fate. Instead, they agree with one another, so they roast newbies
one at a time, driving them out of the group, and as a result the
newsgroup is slowly dying for lack of much fresh blood. I expect once
you disentangle yourself from this current argument you'll probably
not bother much with cljp any more, either.

And when one like you showed up that didn't -- [insult deleted]

No. None of the nasty things that you have said or implied about me
are at all true.

Actually, I used to be like you, Wesson. Even when they threw barbs
and stinging remarks and cutting criticisms at me, undeserved ones and
without provocation, I strained to remain polite while firmly
defending myself.

It didn't work.

So I eventually quit the newsgroup. But I google daily for my name,
and for my older handle Twisted, now and again because some people
here have a nasty penchant for badmouthing me behind my back and
nursing grudges for years, as the sudden appearance of new anti-
Twisted insults in this group yesterday, after months of my absence,
has amply demonstrated. Obviously you've been infected by some anti-
Twisted propaganda that I managed to somehow miss, perhaps because it
was communicated in private or something.

After you leave, you may want to google your name from time to time to
make sure nobody's muttering nasty things about you in here.

And get that anti-Twisted propaganda out of your head! None of it's
true. None of the nasty things that anyone has ever said or implied
about me are at all true.

 

[Jerry Gerrone]

Nobody suggested catering to developers that don't know how to find
stuff. The claim I made that you have somehow [suspected implied insult
deleted]

None of the nasty things that you have said or implied about me are at
all true.

 

[Joshua Cranmer]

Nobody suggested catering to developers that don't know how to find
stuff. The claim I made that you have somehow [suspected implied insult
deleted]

None of the nasty things that you have said or implied about me are at
all true.

Wow, getting all uptight about a typo!

Note: "twisted" in this case is the past participle form of the verb "to
twist", not a reference to a Usenet poster.

 

[Jerry Gerrone]

That's classic cljp regular behavior, alright. I see that things
haven't changed in the years since my last post here. Let me guess,
newbies still get hazed mercilessly, too? And Lew, Arne, and Peter
Duniho are the main triad of evil, with occasional flamey
contributions by the rest of the usual suspects from way back when?

[calls me a liar]

No. None of the nasty things that you have said or implied about me
are at all true.

I typically find that if Lew and Arne are flaming someone, there is a
reason.

I don't.