in reply to RE: (Ovid - question your posting strategy) in thread What Data::Dumper dumps is not necessarily what is there
We're just not getting through to you, are we?
This is a shortcoming of Perl. Who the hell decided to permit overloading of some of the operators and not all? It's inconsistent. It leads to shortcomings in everything which wants to take advantage of overloading. Why shouldn't I expect Perl to be more useful in this respect?
In your original post, you imply that Damian had some choice about
overloading =~ or not.
This means you jumped to the gun about
finding blame for some error, simply because you lacked some understanding.
What I said in the title is exactly right based on both merlyn's response and what the author of the module Damian Conway said.
A documentation error in an example is hardly
grounds for "doesn't work as advertised". Had you read the surrounding text,
you would have realized that the example was in error, not that there were bugs
in the code. Again,
this means you jumped to the gun about
finding blame for some error, simply because you lacked some understanding.
There seemed to be an error in my program and Perl certainly did not alert me to it,
But there was no error in your program. It was a syntactically valid program.
Again,
this means you jumped to the gun about
finding blame for some error, simply because you lacked some understanding.
Do you see the pattern here? This is what ovid was also trying to point out.
You must stop before posting, and ask yourself "maybe there's nothing wrong
out there... and it's just something I don't yet understand".
-- Randal L. Schwartz, Perl hacker
RE: RE: RE: (Ovid - question your posting strategy)
by princepawn (Parson) on Oct 24, 2000 at 16:10 UTC
|
I thought about this overnight, and in each case, you are right: I lacked some understanding
I think my mode of putting forth assertions has to do with having spent 5 years as a biological scientist. As biologists, we often write papers and abstracts where we make statements. For example, my professor's chief rival published a paper entitled: "Synaptic Integration is Linear and Position-Independent". We then responded with an abstract entitled "Non-linear and position-dependent synaptic integration in CA Pyramidal Cells."
Now, although it was not stated in either title, the key phrase of merlyn's response to me, is implicitly implied in both titles: based on our current understanding
They, as scientists, and we also, as scientists, had a hypothesis, some tests, and some conclusions which resulted in a conclusion. Neither group of researchers was under the illusion that our paper was the final word on the topic of synaptic integration, yet each title was made as what you guys would seem to think is a statement of fact, when it really is: a statement of fact based on our current understanding
Thus, when I, or actually anyone posts to this board, other than maybe the 1 or 2 people who really, really know Perl entirely, they are making a statement based on their limited understanding. And this should be obvious and understood... and in fact entertaining. It always tickles me when someone who has been using Perl for 1 month of so posts up a message like "Perl compiler broken" when actually the fault lay with their program.
I can't say I find it appealing to spend a lot of time writing mealy-mouthed, squirrely "well, you know guys, I have this error. And you know, it might just be me, but it seems there's a bug somewhere in Perl." Its much more to the point to state your position and the data supporting it, and then receive whatever rebuttle or higher advisement that others are willing to impart.
But, then again, the majority of the people here seem to think I need to modify my behavior to suit them, so I am willing to at least get some input from you if you have anything to say.
| [reply] [Watch: Dir/Any] |
|
princepawn,
With all due respect, I have personally found it helpful to take the extra time to be self-effacing in online circles.
As a scientist, I'm sure you can appreciate the importance of proper data collection techniques. Is it not wise and proper to ensure the collection process doesn't taint (pun intended) the experiments, the results, and the conclusions being observed?
Besides, what's wrong with stepping back and mentally testing your conclusions and hypotheses against the observed results? This is, in many ways, basic programming.
To provide a perl example from my own experience, I had a dickens of a time getting sub's to work when I first tackled them. It finally worked when I prepended an ampersand to the name of the subroutine. I (erroneously) assumed that perl requires ampersands when invoking custom procedures, much the same way it requires symbols in front of variables.
Since then, I've learned that the rules are more subtle and more flexible and I've modified my mental understanding to allow for that.
Remember Occam's Razor: When faced with more than one equally viable explanation for a problem, more often than not, the simplest solution is the right one. (Poorly paraphrased, I know, but you get the idea.)
Just a thought...
| [reply] [Watch: Dir/Any] |
|
I can't say I find it appealing to spend a lot of time writing mealy-mouthed, squirrely "well, you know guys, I
have this error. And you know, it might just be me, but it seems there's a bug somewhere in Perl." Its much
more to the point to state your position and the data supporting it, and then receive whatever rebuttle or
higher advisement that others are willing to impart.
You don't need to be mealy-mouthed (What a great phrase...)
but you need to tone down the assertion knob a bit.
If you are willing to admit your own ignorance (and as a
scientist you'd better be =) then try stating these calls
in the "Is this really the way it is supposed to work?"
form. Honestly, the trouble you stir up is quite worthwhile
overall. I just think you are raising hackles by expecting
and denouncing. That is bad science. =) Examine and experiment,
postulate and test, publish. What you are doing is treating
the theory of how perl should behave as the problem. It isn't.
Treat perl as a natural phenomenon to be studied.
It exists (-e /usr/bin/perl) and can be tested. People on
here are reacting badly because you keep saying nature
won't abide by the math you've worked out. =)
Anyhoo, don't go away mad, I'm learning from your tinkering
and from picking through the ashes in the aftermath!
--
$you = new YOU;
honk() if $you->love(perl)
| [reply] [Watch: Dir/Any] |
|
I appreciate the explanation of your thinking, and I understand a great deal
of it, but the logical gap I see is that in your papers' titles
the "our" refers to the biology community as a whole (please correct me if I'm wrong), but at
The Monastery the "our" is just you, and you (as you freely admit)
don't fully understand Perl (of course that still puts you waaaay
ahead of me!).
In your technical papers you have likely
done vast research into other papers on the topic, distilling the
state of the art and sum of knowledge to date, from which you
then extrapolate, probably adding new empirical evidence. This
puts you in the unique position, for a short time at least, of
being close to the world's authority on the topic (allowing the "our" to
include the rest of the community). In
your postings here this level of exploration seems unlikely,
and in the vast majority of posting here (not just yours),
it is usually shown that the problem or question being posed
already has a long-standing answer or solution.
As an aside, I don't believe I've ever seen an engineering
paper titled so as to present a conclusion as fact. We tend
to always assume that we are exploring and estimating, not
revealing some basic truth. In later papers we refine our
estimates and clarify our understanding, but we never have
the nerve to say "A is B". I guess that's the difference
between Science and Applied Science *grin*.
Humbly offered without prejudice! (how's that for mealy-mouthed? ;-)
| [reply] [Watch: Dir/Any] |
|
|