Andrew DeFaria said:
Ugh your circularly illogical arguments are really tiring...
Just a side note: I hope your source code uses more white space compared
to your Usenet posts. You even remove the white space I have included
for readability. Let me guess, you spend a lot of time when working in a
team on "correcting" the /style/ of others. And you call that working
very hard on a project ;-)
If that rock is stupid enough to keep coming back for more, sure why
not?
You're reading between the lines was that there's some hard and fast
rule.
"In general it's preferable"
How flexible is that? Also your other statements showed that you have
quite a rigid opinion on using external tools (lazy (in a bad way) was
one of them)
Right, yet you put words in my mouth (and David's BTW) that I've said
"thou must rigidly adhere to this rule" when neither of us said that.
"In general it's preferable" sounds quite rigid to me. Even if it's not
rigid, the way it was expressed it can be used as a straw man at all
times. You know, when one programmer looks over the code of someone else
and just for the sake of argument says: you n00b don't call external
programs because there is a huge fork overhead, and it's not portable
(even if neither are an issue). You probably recognize the first
programmer.
You obviously don't understand that there is indeed a real difference
between "In general this is a good idea" to "thou must do X" but
you'll argue with a rock that they are exactly the same thing!
They might mean different things, but the former is often used in
various arguments like it's the latter. I have surely read your posts
this way. I doubt it's my bad.
And by and large I'd say that 70-80% of the time the implementor does
not spend even a second of time making an informed and thoughtful
decision between "should I implement this in an efficient and portable
manner or should I just call X". Often they call X because that's the
only way they know to do it.
I am convinced that there is more Perl (or any code in general) out
there that suffers from the implementor writing a very bad
implementation of something that is already available either as a
library or as an external tool. "Rules" (for your sake) like "In general
it's preferable" only give them a few meters more rope to hang
themselves (and everybody else involved).
They do it, as you freely admit to,
because they are lazy and it's "easier" than thinking or typing (still
wish to brag about being lazy - you probably do. Do you realize how
foolish that makes you appear?).
No, because I don't call that lazy but underskilled.
And often when confronted why they
chose to use X instead of something more efficient or portable they
often don't have any particularly convincing argument other than "well
it was easy/quick/a one time script/I'm lazy/etc".
Yup, for the same reason people come up with /huge/ fork overheads and
"but the ZX Spectrum doesn't have ls built in ROM".
I know, I've asked
and these are the answers I receive 70-80% of the time.
So you're just saying that a majority of the programmers are
underskilled. Doesn't amaze me the least. Question is: how often did
people say that they did it and you disagreed with them without even
taken into account the real situation and just grabbed at straws like
"fork overhead" and "non-portable" just because of "your" "in general".
God you are exceptionally obtuse and argumentative. Let's be complete
shall we?
Here's the whole quote:
It's /generally/
Depends on what you're doing of course.
Do you see any example Perl code in there? I see two. One is `cat
somefile.txt` and the other is `ls /some/directory`. Those were the
examples I was talking about you nimrod! You sir are an intellectually
dishonest man and really not worth arguing with.
Yet I am convinced you can't resist replying 5 more times ;-). But even
with cat and ls: "it depends on what you're doing of course".
So, IOW, when confronted with a direct question you avoid it.
Nope: I said: depends on what you're doing.
This
combined with the above obvious misquotation, lack of reading and
comprehension skills or pure intellectual dishonesty severely lowers
your credibility in many people's eyes.
Ah, you are now representing a group of people? Or do you think your
argument gets better the more you drag into it? Like I said, Abigail
provided an example involving grep. I did miss your reply to that
however.
There's a world of difference between a recommendation and a rigid
rule as you claim.
Sure. The said thing is people forget that often when they look over the
code of someone else. Then suddenly overheads and portability is dragged
into the discussion even if it's not important. You, in my opinion, did
this.
You're all over the map in your argument, use
strawmen arguments, deliberately misquote context and you are evasive
when asked a direct question. In short you're not worth arguing with
as you are dishonest at best.
argumentum ad hominem or: picture, or it didn't happen.
[ Usenet ]
From what I can tell this is where a bunch of losers who like to
argue
hang out. Which is why I rarely post. However I thought that
occasionally I could make a point and people who have more integrity
than you have shown here would benefit. Apparently I misjudged the
number of people here with integrity! Either that or they are very
quiet...
Maybe if you stop making all that noise. A lot of people have kill filed
you just because you ignored the posting guidelines on purpose.
I agree that one shouldn't stick to rules for the sake of rules. But
ignoring a guideline just because you consider it losing face /is/
losing face big time. Can you explain what the use is of posting both in
plain text and HTML in a group that prefers for several reasons plain
text? Ignoring a guide line because you can is as stupid as turning a
gut feeling in a guide line wether it's strict and rigid or not.
If you write a Perl program that has to be portable "a [external]
program that does already its work perfectly" implies that it's
available.
No it doesn't.
Odd, how can it work perfectly if it isn't available?
It's a good thing to do - despite what you think. Does it have to be
done 100% of the time. Obviously not.
It's only a good thing to do when it's a requirement. If it's not then I
prefer to code as I consider it the best. Which means that if I consider
a non-portable piece of code the best I just do it.
Just writing portable code because "It's a good thing" is silly to say
the least.
Nor have you. Abigail has, but you ignored that. Says a lot.
While we are talking about programming here we are arguing about
semantic misunderstandings caused by our usage of English prose here.
Your misunderstandings, misquotings and the like plainly show this.
I have the feeling that the lead cause of what you consider
"misunderstandings" is that you put your head in your ass a bit too
strong, and now it's stuck. Or maybe it has been stuck there for a
while, it's a bit hard to see the difference without an actual picture.
