Front page | perl.perl5.porters |
Postings from May 2003
RE: That which is better left unsed: Removing language digression s
From:
Orton, Yves
Date:
May 14, 2003 09:19
Subject:
RE: That which is better left unsed: Removing language digression s
Message ID:
71B318898201D311845C0008C75DAD1C08960A55@defra1ex2
> > >I've come to the conculsion that most of the direct comparisions to
> > >other languages in the Perl documentation are not particularly relevent
> > >anymore.
> >
> > Sounds like you've got some religious axe to grind. Feel free to
> > keep the axe, but stop cutting down the documentation!
> >
> > I find the comparisons plenty relevant,
>
> Of course you do, you probably know awk! :)
I have to say that I dont know awk. And I do agree with you that perhaps
perlsyn is an inappropriate location for so many references to other
languages.
But I do feel strongly that these references are very useful to the perl
community. We have a strong tradition of horizon extending in Perl. What I
mean
is that some of these references subconciously help less experienced
programers
get over the fear of the unknown. By reading a Perl doc full of references
to
other languages the reader gets a message that "by learning perl I am also
learning
a bit of these other things too."
C is a good example. I have used my Perl experience to leverage myself into
both C,
C++ and C#. All the little tidbits that I have picked up in the perl
documentation,
p5p, and in other perl related venues has been very useful to me. I now can
write
a C/XS module without wanting to kill myself. :-)
So I think the references overall are net positive for the community and
shouldn't
be excised altogether, nor as exhaustively as you indicated you might.
> I've got the interesting mindset of being very fluent with Perl *without*
> being fluent in traditional Unix tools.
Actually you should realize that these days this is hardly uncommon. I think
it is
_highly_ likely that in pure number terms there are more Win32 users than
*nix.
But again, I think removing *nix references from the documentation for this
reason
is as foolish as removing or overlooking win32 specific material in the
documentation.
Eventually the Win32 user gets chucked on a *nix box, and hey he finds out
that
a lot of that stuff that hes been noticing but not paying much attention to
is
actually a lot more useful than he thought.
I can say with no hesitation that I am that Win32 user. The exposure that I
have recevied
to *nix concepts due to my interest in Perl has been absolutely invaluable
to me.
In fact I have on a number of occasions argued that one advantage of
learning perl on Win32
is that not only do you learn a cool language you get a bunch *nix exposure
for free too.
This obviously applies to the *nix programmer as well. When she is forced to
switch over
she is real happy that all those *nix concepts have been more or less ported
over to the win32
arena in a way that she wont notice much difference.
> References to these things do not appear natural or relevant to me, even
> though I understand them, and I feel this reflects a growing number of
> Perl users. We should probably listen to that and purge Perl of Unixisms
> for the sake of Unixisms where possible.
Absolutely not. And I'm an almost pure Win32 user. Systematically excising
*nix references
from the Perl documentation would IMO verge on criminal recklessnes. Let me
repeat that
im a win32 user almost solely and I still feel this way.
> I guess what I'm trying to say is most of us have Unix myopia
> and can't see why these references might be irrelevant.
I strongly agree with you that there is a definite aura of Unix myopia in
the
Perl community, and that it should be confronted and dealt with. On many
occasions
I have bitched about this to my friends and colleagues.
However the way to confront it is NOT to REMOVE OS specific references, but
rather to
add MORE references to OTHER OS's. This can only be for the long term
benefit of the
community.
An immediate topic along these lines is the documenation of -X. This
documenation should
include more references to what the switches mean on other OS's and maybe a
slight toning
down of the *nix specific references. (This section will be _many_ peoples
first encounter
with that ever so unixy beast the INODE.) For instance -c on Win32 returns
the "creation
time" of the file (FWIW).
While I did say toning down I do not mean "outright exclusion".
> > and even useful for the
> > fast-aging hordes of UNIX sysadms who happen to know sed, awk
> > and C, but never managed to find the time to do perl.
>
> Extending your rationale, why don't we litter the man pages with
languages
> a reader of the documentation is more likely to know? PHP, Java, Python,
> Ruby, Visual BASIC...
I agree fully. More references to more languages is a good thing. If we can
encourage people
to switch to Perl from one of them by making the docs a little more
appealing to newcomers
from these backgrounds then I think that is a Good Thing.
> Why don't we explain the file operators in terms of
> the differences between Unix and Mainframe file philosophies? And the
> whole thing needs to be adjusted to explain the contrasts between the
> Unix command-line philosophy and MacOS Classic which has no
> command-line tradition.
I beleive that we should do so. In fact above I argued so explicitly.
Although I think that "going by the numbers" is probably fair in how we
choose how much
effort gets expended on a particular OS.
Im guessing but I reckon that user levels are something like:
Win32
*nix
Mainframe
MacOS
No doubt somebody has a better idea of the breakdown than I do.
>
> Obviously doing this would swamp the text and still leave us
> missing some
> part of the Perl community. Awk/sed/C are mentioned, and not
> Java/Python/PHP, not because its relevent but because its historical.
> History is interesting, but it doesn't necessarily help teach
> languages.
On the contrary. Understanding a bit about history is essential to
understand why we do
what we do. A good example is Dominus's Coping with Scoping. In order to
explain why
we have scoped variables he needed to explain how things were done before
scoping
was introduced. Your point about the horse buggy is fair. The comparisons
need to be
somewhat relevent. I mean can you imagine Dominus writing soemthing like
"global variable clashes weren't a real problem in Babbages time because..."
> If we want to teach Perl to <insert language here> programmers, expand
> perltrap into a seperate perl<language> man pages and do a proper
> comparision. It has the advantage of not being scattered all
> over the docs, providing a location for a well-structured discussion, and
> not getting in the way of people who couldn't care less how Pascal defines
> its compound statements.
I think this is a really good idea. But I dont think that it should be the
basis for
removing the scattered references in the documentation.
Cheers,
yves