develooper Front page | perl.perl5.porters | Postings from May 2003

Re: That which is better left unsed: Removing language digressions

From:
Michael G Schwern
Date:
May 13, 2003 23:34
Subject:
Re: That which is better left unsed: Removing language digressions
Message ID:
20030514063408.GE22001@windhund.schwern.org
On Tue, May 13, 2003 at 10:27:52PM -0700, Gurusamy Sarathy wrote:
> On Tue, 13 May 2003 18:16:37 PDT, Michael G Schwern wrote:
> >The recent threads about perlsyn made me take another look at the Perl
> >documentation.  It talks an awful lot about other languages to the
> >point of sometimes obscuring the point: Perl.
> 
> I think you missed the point.  The references to sed/awk/C/etc are
> rationale for why certain features are the way they are, and how
> Perl improves upon than those other tools.  Removing these
> references is tantamount to removing the rationale, and the useful
> parallels.

Of course, parallels are only useful if you understand what its being
compared against.  Awk, sed and C are not particularly well known anymore.
If we wanted to draw useful parallels we'd use PHP, Visual BASIC and
Javascript, but that's a dead end as explained below.

Its kind of like opening up your new car's Driver's Manual and having it
explain that the steering wheel works like it does and not like the old 
leather harnesses on horse-drawn buggies.  Anachronistic and it doesn't
help you drive a car.

I'd agree with you about rationale if they were being used for that purpose.
In reality, other languages aren't used so much for rationale but for 
contrast which falls flat on its face unless you're familiar with the
other language.  If you have a look at the perlsyn_unsed patch I posted, 
most of what's been removed is not rationale but contrast.  Let's have a 
look at some:

Old
    "Note that, unlike C and Pascal, [compound statements] are defined in
     terms of BLOCKs, not statements."
New
    "Note that [compound statements] are defined in terms of BLOCKs, not
     statements."

Mentioning C and Pascal offers no rationale for why compound statements
act the way they do in Perl, except maybe pointing out a feature that 
Perl lacks.  If there was to be a rationale it would be about why Perl
*doesn't* support this feature from C and Pascal.  But only C and Pascal
programmers would be wondering, so its better explained in perltrap.

Old
    "If there is a continue BLOCK, it is always executed just before the
     conditional is about to be evaluated again, just like the third part
     of a for loop in C."
New
    "If there is a continue BLOCK, it is always executed just before the
     conditional is about to be evaluated again."

Here, the reference to C is used for clarification, not rationale.  It is
only useful to the reader if they are familiar with C, a shrinking
population.  Otherwise its just so much cruft.  If a clarification is
needed it would better be done with an example.


Now for some stuff I left in:

    "Perl's C-style for loop..."

"C-style for loop" is such a common term I felt it more universal than
others.  Furthermore, its short, doesn't obscure the explaination of what
a C-style for loop is and is supported by a good example.

    "Here's how a C programmer might code up a particular algorithm in Perl:"

The following examples of C-style for loop vs Perl foreach with labels
neatly explains why we have two for loops in Perl.  The reader does not
need to understand C to get it.

    "The author of Perl has never felt the need to use this form of goto
     (in Perl, that is--C is another matter."

This is an indirect rationale for why goto LABEL exists in Perl.  Its also
amusing.  Finally, its in the middle of a discussion that's already a bit 
esoteric so throwing in a bit of extra history can't hurt.


> >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'm in the position of being a *native* Perl programmer.  I never 
really learned awk, sed, shell or C.  I know how to use Unix but I never
was a sysadmin.  Unlike many others for whom Perl is their first language, 
I've been doing it for almost eight years now, pre .com boom.  I've got the 
interesting mindset of being very fluent with Perl *without* being fluent 
in traditional Unix tools.

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.

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.


> 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...  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.

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.

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.
 

-- 
"Let's face it," said bearded Rusty Simmons, opening a can after the
race.  "This is a good excuse to drink some beer."  At 10:30 in the
morning?  "Well, it's past noon in Dublin," said teammate Mike
[Joseph] Schwern.  "It's our duty."
    -- "Sure, and It's a Great Day for Irish Runners" 
       Newsday, Sunday, March 20, 1988



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About