Perldocs for Schwartzian transforms?

Discussion in 'Perl Misc' started by jl_post@hotmail.com, Dec 9, 2005.

  1. Guest

    Dear Perl Community,

    Are there any perldocs that cover Schwartzian transforms?

    I tried:

    perldoc -q Schwartz

    and also searched for "Schwartz" in "perldoc perltoc" but couldn't find
    any mention of them.

    I did, however, find a mention in:

    perldoc perlfaq4

    (which I found again with "perldoc -f sort") but it only briefly
    touches upon the Schwartzian transform. I was wondering if there are
    any perldocs that might explain it in more detail.

    Thanks for any responses.

    -- Jean-Luc
    , Dec 9, 2005
    #1
    1. Advertising

  2. wrote:
    > Are there any perldocs that cover Schwartzian transforms?

    [...]
    > touches upon the Schwartzian transform. I was wondering if there are
    > any perldocs that might explain it in more detail.


    None that I am aware of (which doesn't mean there aren;t any), but there are
    numerous articles on Google.

    jue
    Jürgen Exner, Dec 9, 2005
    #2
    1. Advertising

  3. "" <> wrote in
    news::

    > Dear Perl Community,
    >
    > Are there any perldocs that cover Schwartzian transforms?
    >
    > I tried:
    >
    > perldoc -q Schwartz
    >
    > and also searched for "Schwartz" in "perldoc perltoc" but couldn't find
    > any mention of them.
    >
    > I did, however, find a mention in:
    >
    > perldoc perlfaq4
    >
    > (which I found again with "perldoc -f sort") but


    ITYM perldoc -q sort

    > I was wondering if there are
    > any perldocs that might explain it in more detail.


    Does it have to be in perldoc?

    A simple Google search yields the following links in the first few results:

    <URL:http://www.stonehenge.com/merlyn/UnixReview/col06.html>

    <URL:http://en.wikipedia.org/wiki/Schwartzian_Transform>

    <URL:http://perl.plover.com/yak/hw1/samples/slide004.html>

    I am assuming you have already done this search, and looked at the
    documents above.

    Sinan
    A. Sinan Unur, Dec 9, 2005
    #3
  4. Tim Heaney Guest

    Tim Heaney, Dec 9, 2005
    #4
  5. Guest

    > "" <> wrote in
    > >
    > > Are there any perldocs that cover Schwartzian transforms?
    > >
    > > I was wondering if there are
    > > any perldocs that might explain it in more detail.


    A. Sinan Unur replied:
    >
    > Does it have to be in perldoc?


    It would be nice if there was a perldoc explanation.

    The reason I prefer the perldocs is because I always encourage those
    newer to Perl to use the perldocs to look up anything they don't know
    how to use. Don't know what a function does? Look it up with "perldoc
    -f function". Don't know how to use a module? Look it up with
    "perldoc Module". Want to know how to do a specific thing in Perl?
    Try "perldoc -q keyword" or search for it in "perldoc perl" and
    "perldoc perltoc".

    I've found that I sometimes have to explain my code at times,
    otherwise other people will copy it into their own Perl programs not
    really understanding what it means. For example, I once used the
    following code in my own program:

    use File::Find;
    find(\&wanted, @directories_to_seach);
    sub wanted
    {
    ...
    }

    This was taken right out of "perldoc File::Find". Well, the program
    worked so well that it was "picked apart" by another programmer.
    Unfortunately, since he didn't quite understand what the File::Find
    module did (he thought he did), he used it where he really meant to use
    opendir() and readdir() instead.

    He complained that the code was doing things to files he didn't
    specify, not realizing that File::Find operates on all files
    *recursively* -- which, after several minutes of interrogation (it's
    often difficult to understand other people when they don't clearly
    explain what they want), I discovered was exactly what he didn't want.

    Therefore, I've taken to adding comments like:

    # The following three lines of code were lifted
    # right out of "perldoc File::Find":

    before any code that, for the most part, I didn't write myself. That
    way any maintainer (which could conceivably be me, in a few years) can
    look up its purpose and use without having to resort to guessing.
    (Unfortunately, there will always be people who remain confused because
    they ignore the help written in the comments, but I think that's more
    the maintainer's problem than the original code writer's.)

    So if I ever wanted to write a Schwartian Transform to sort files by
    file size, I might write something like this:

    # The following line of code uses a Schwartzian
    # Transform to sort the files by file size (read
    # "perldoc perlfaq4" to learn more about
    # Schwartzian Transforms):
    @sorted = map { $_->[0] }
    sort { $a->[1] <=> $b->[1] }
    map { [ $_, -s $_ ] } @files;

    Without the comment, a person who has never seen a Schwartzian
    Transform before would have to study the code very hard to figure out
    that the files are being sorted by size, and he/she would still have no
    clue why I did it in such a seemingly strange way. He/She would have
    no idea what to search for, even if he/she did think to look up that
    construct on the web or in the perldocs.

    I tell people who write Perl code (or any code, really) to ask
    themselves: "If a maintainer reads the block of code I have just
    written, will he/she have a difficult time understanding what I wrote
    and what it's supposed to do, assuming they don't know my thought
    process beforehand? If so, I should either simplify the code (so that
    what the code does is clear to those who don't necessarily know my
    intentions) or, if that's not possible, explain my intentions and what
    the code is supposed to do right above the block of code in the form of
    a comment (which will make it easier to maintain and distinguish any
    bugs that creep in there by future maintainers). So many times I have
    seen code that looks like could be a bug -- but I'm not sure if it is
    or not because I have no way of knowing what the code is *supposed* to
    be doing.

    So I encourage people to use the perldocs and to reference them in
    their code whenever appropriate. Granted, referencing a web page can
    also work, but in my experience a good web page may not be around
    several years later when a piece of code is being maintained. In
    addition, I trust explanations and code in the perldocs more than I do
    on just any web page. For these reasons, I prefer referencing perldoc
    documentation over web pages.

    That isn't to say that the web page explanations aren't good. The
    wikipedia link is good, as many people are encouraged to look up things
    there anyway, and I just might cite that next time I use a Schwartzian
    Transform.

    I also happen to think that if good Perl programmers are expected to
    know of a particular construct (like the Schwartzian Transform), then
    it should be explained in the perldocs. I constantly tell new Perl
    programmers that they should always favor the Perl community's
    convention of doing things (over some other language's convention) even
    if it goes against what their first programming language teacher told
    them (for example, always using prototypes, despite what their
    professor said, is not always a good idea in Perl -- just ask Tom
    Christiansen).

    So if they can't find any mention of a way of doing something in the
    perldocs, then they should either not use it, or explain it clearly in
    the form of comments. Even if it is in the perldocs and still looks
    strange, they should at least give a perldoc reference so that any
    decent maintainer (who cannot reasonably be expected to understand
    every construct he/she encounters) can look it up and have help
    understanding the code.

    Sorry... this post turned out longer than I intended.

    But anyway, thanks to everyone who provided the links. I can always
    reference the Wikipedia article, and be reasonably certain that it will
    still be around when a future maintainer needs it to be.

    -- Jean-Luc Romano
    , Dec 11, 2005
    #5
  6. "" <> wrote in
    news::

    >> "" <> wrote in
    >> >
    >> > Are there any perldocs that cover Schwartzian transforms?
    >> >
    >> > I was wondering if there are
    >> > any perldocs that might explain it in more detail.

    >
    > A. Sinan Unur replied:
    >>
    >> Does it have to be in perldoc?

    >
    > It would be nice if there was a perldoc explanation.
    >
    > The reason I prefer the perldocs is because I always encourage
    > those newer to Perl to use the perldocs to look up anything they
    > don't know how to use.


    <snip>

    Does every single programming technique, algorithm, and idiom have to be
    in perldoc?

    > # The following line of code uses a Schwartzian
    > # Transform to sort the files by file size (read
    > # "perldoc perlfaq4" to learn more about
    > # Schwartzian Transforms):


    What's wrong with Randal's original article in Unix Review (which also
    appeared in print, in case you are worried about links disappearing)?

    <URL:http://www.stonehenge.com/merlyn/UnixReview/col06.html>

    > So I encourage people to use the perldocs and to reference them in
    > their code whenever appropriate.


    OK.

    > I trust explanations and code in the perldocs more than I do
    > on just any web page.


    Well, the link above is not just any web page. Have you ever wondered
    where the "Schwartz" in "Schwartzian Transform" comes from?

    > I also happen to think that if good Perl programmers are expected to
    > know of a particular construct (like the Schwartzian Transform), then
    > it should be explained in the perldocs.


    Are you volunteering to write a new FAQ entry? That would be a valuable
    contribution indeed.

    Or, maybe, you could use Uri Guttman's excellent Sort::Maker to
    construct the sort routine, and get the description of the Schwartzian
    Transform (along with some others) for free.

    Sinan
    --
    A. Sinan Unur <>
    (reverse each component and remove .invalid for email address)

    comp.lang.perl.misc guidelines on the WWW:
    http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
    A. Sinan Unur, Dec 11, 2005
    #6
  7. Guest

    > >> "" <> wrote:
    > >
    > > The reason I prefer the perldocs is because I always encourage
    > > those newer to Perl to use the perldocs to look up anything they
    > > don't know how to use.


    > A. Sinan Unur replied:
    >
    > Does every single programming technique, algorithm, and idiom have to be
    > in perldoc?


    No. Anything that you would expect a decent Perl
    programmer/maintainer to know doesn't have to be documented. (Of
    course, we could get into long debates as to what constitutes a
    "decent" Perl programmer and what he/she is expected to know, but I
    tend to consider that such a person is one who is familiar with almost
    all of the concepts in O'Reilly's "Learning Perl".)

    As for other programming techniques, algorithms, and idioms that are
    not immediately apparent to a maintainer, they don't have to be in
    perldocs as long as they are either explained in the form of comments
    (or accompanying documentation), or they are written along with a
    reference pointing to information needed to understand the code.

    Consider the code you see in "perldoc -m Math::BigInt". Looking
    through the code, I see the following comments:

    # GCD -- Euclids algorithm, variant C (Knuth Vol 3, pg 341 ff)

    and

    # multiply two numbers -- stolen from Knuth Vol 2 pg 233

    Personally, I think these are great comments because they explain
    exactly where the code was derived from. In my opinion, it's not
    reasonable that a decent Perl coder could understand the intention of
    all the code in Math::BigInt without outside help, so it's good to know
    that a reference point is provided in case I decide I need more
    information to help me. In case I ever I have to track down a bug
    somewhere in the Math::BigInt module (and it has happened on one
    occasion), I won't have to guess as to what the right operation,
    calculation, or behavior is meant to be; I can just look it up in the
    references given. Granted, the comments assume that a copy of that
    book will be available, but it's better than no comment at all.

    Consider this example: 0n page 233 of a certain administrator's
    handbook which I won't name here, I saw the following (unexplained)
    line of code:

    map { $String{$StringIndex{$_}} = $_; } ( keys( %StringIndex ) );

    What is it doing, exactly? First of all, we can tell that the code is
    not very well written, otherwise map() wouldn't have been used in void
    context (foreach would have been a better choice). In addition, "use
    strict" and "use warnings" weren't used (there's no way for you to know
    just by looking at this one line of code; I just know because I saw the
    full script).

    It took me about five minutes to study this one line of code before
    I realized what it was doing. It was basically doing the same thing as
    the following line of code:

    %String = reverse %StringIndex;

    Now, which line of code is easier to understand and comprehend? For
    me, the second one is. I must admit, however, that the second line is
    only easier for me because I learned about it in the O'Reilly "Learning
    Perl" book. If I hadn't, the line calling reverse() might make no
    sense to me. I might have preferred the following lines instead:

    while (($k,$v) = each %StringIndex)
    {
    $String{$v} = $k;
    }

    or even:

    $String{ $StringIndex{$_} } = $_ foreach keys %StringIndex;

    But whichever way I choose, there is a reasonable chance that a
    maintainer will not know what I meant, and the line looks no more
    comprehensible than the first map() example. (It's my opinion that
    they should know about the reverse() example since that's covered in
    "Learning Perl", but that's not always the case, unfortunately.)
    Therefore, I don't think it's a bad idea to include a comment like:

    # Create a hash that's the reverse of %StringIndex
    # (so that the keys are not values and vice-versa):
    %String = reverse %StringIndex;

    Even if that comment were used on the map() line of code above, it
    would significantly help the maintainer understand what is going on.


    > What's wrong with Randal's original article in Unix Review (which also
    > appeared in print, in case you are worried about links disappearing)?


    Absolutely nothing is wrong. I never said it was a bad review and
    I'm not opposed to citing it. I just favor perldocs because they are
    available even when a user has no internet connection (or is at the
    moment having trouble with it) and will never be a stale link (even if
    an article appeared in print). In my opinion, perldocs are just
    usually easier to use, and I've found that the more you require of
    maintainers to jump through hoops to get information, the less likely
    they are to do so (even if the link is valid and good).


    > Are you volunteering to write a new FAQ entry? That would be a valuable
    > contribution indeed.


    To be honest, I haven't thought about that until you mentioned it.
    I suppose that's something I could try. How would I go abuot doing it?
    (I briefly searched Google and the perldocs and the closest thing I
    could find to submitting a perldoc was in "perldoc Net::libnetFAQ"
    which says to mail contributions to g barr at pobox dot com. If I'm
    missing a crucial page or something, let me know.)

    About my opinion (which says that code not immediately
    understandable to a decent programmer should always be accompanied by
    documentation (or at least a reference) that explains the intent of the
    code): I've discussed this opinion of mine at length with several
    programmers throughout the years and so far none of them share my
    opinion (some think it might be a good idea, however). So if you
    disagree with my opinion, know that you are in the majority. However,
    this remains my personal opinion and I find that the more I practice it
    in my code, the more maintainers understand my code and benefit from
    it.

    Anyway, thanks for your input, Sinan.

    -- Jean-Luc
    , Dec 11, 2005
    #7
  8. John Bokma Guest

    "" <> wrote:

    > Consider this example: 0n page 233 of a certain administrator's
    > handbook which I won't name here, I saw the following (unexplained)
    > line of code:
    >
    > map { $String{$StringIndex{$_}} = $_; } ( keys( %StringIndex ) );
    >
    > What is it doing, exactly? First of all, we can tell that the code is
    > not very well written, otherwise map() wouldn't have been used in void
    > context (foreach would have been a better choice).


    IIRC map in void context has been optimized. (Note: I do not say the above
    piece of code is good or bad).

    Remember, ages ago it was bad to write: for ( 1 .. 10_000_000 )

    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    I ploink googlegroups.com :)
    John Bokma, Dec 11, 2005
    #8
  9. "" <> wrote in
    news::

    > About my opinion (which says that code not immediately
    > understandable to a decent programmer should always be accompanied by
    > documentation (or at least a reference) that explains the intent of
    > the code):


    I think you are cheating a little here. Your actual stated opinion seems
    to me that everything that you might ever want to reference should be
    included in the standard Perl documentation. That is where I am a little
    baffled by your arguments. No one can argue with the proposition that
    when you do something clever, you should put something that explains
    where that came from.

    > As for other programming techniques, algorithms, and idioms that are
    > not immediately apparent to a maintainer, they don't have to be in
    > perldocs as long as they are either explained in the form of comments


    I really don't understand you, I am afraid. Do you propose that what
    gets included in the standard Perl distribution should depend on what
    programmers put in their comments?

    > (or accompanying documentation), or they are written along with a
    > reference pointing to information needed to understand the code.
    >
    > Consider the code you see in "perldoc -m Math::BigInt". Looking
    > through the code, I see the following comments:
    >
    > # GCD -- Euclids algorithm, variant C (Knuth Vol 3, pg 341 ff)


    So, in the case of Schwartzian transform, it should be fine to reference
    Randal's original article, and move on, instead of insisting that
    Schwartzian transform should be explained in the standard Perl
    documentation.

    That's the point I am trying to make. You seem to want to go off on
    tangents about dimwit programmers who cannot figure out File::Find, or
    map in void context, or comments. The issues you raise are all valid,
    but irrelevant to the question I asked. For the record, that question
    was: "Does the explanation of the "Schwartzian Transform" -- a general
    algorithm -- need to be included with Perl?"

    Aaaanyway, I am probably becoming too pedantic, so I'll stop now.

    Sinan
    --
    A. Sinan Unur <>
    (reverse each component and remove .invalid for email address)

    comp.lang.perl.misc guidelines on the WWW:
    http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
    A. Sinan Unur, Dec 12, 2005
    #9
  10. robic0 Guest

    On 11 Dec 2005 22:52:07 GMT, John Bokma <> wrote:

    >"" <> wrote:
    >
    >> Consider this example: 0n page 233 of a certain administrator's
    >> handbook which I won't name here, I saw the following (unexplained)
    >> line of code:
    >>
    >> map { $String{$StringIndex{$_}} = $_; } ( keys( %StringIndex ) );
    >>
    >> What is it doing, exactly? First of all, we can tell that the code is
    >> not very well written, otherwise map() wouldn't have been used in void
    >> context (foreach would have been a better choice).

    >
    >IIRC map in void context has been optimized. (Note: I do not say the above
    >piece of code is good or bad).
    >
    >Remember, ages ago it was bad to write: for ( 1 .. 10_000_000 )


    What does for(1..$somevariable) actually mean? Is it short for some
    C construct? Why is Perl sofuckin much of a child of a prostitute
    whore anyway? Who holds the tribal knowledge of this piece of shit
    jackoff, incomplete, language anyway? A language allowing dll
    interfaces to the os that supposedly legitimizes it. What a real
    honest piece of shit Perl is !!! I saw a C program running yesterday,
    did the same thing as a module on Cpan. The C program ran 100 times
    faster with better results/reliability.

    Explain how Perl is something good to me.......>
    robic0, Dec 12, 2005
    #10
  11. robic0 <> wrote:

    > Explain how Perl is something good to me.......>



    Perl is not good for you.

    Use some other language.

    Is there a problem?


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Dec 12, 2005
    #11
  12. robic0 Guest

    On Sun, 11 Dec 2005 21:42:35 -0600, Tad McClellan
    <> wrote:

    >robic0 <> wrote:
    >


    You forgot the premise asshole........>

    What does for(1..$somevariable) actually mean? Is it short for some
    C construct? Why is Perl sofuckin much of a child of a prostitute
    whore anyway? Who holds the tribal knowledge of this piece of shit
    jackoff, incomplete, language anyway? A language allowing dll
    interfaces to the os that supposedly legitimizes it. What a real
    honest piece of shit Perl is !!! I saw a C program running yesterday,
    did the same thing as a module on Cpan. The C program ran 100 times
    faster with better results/reliability.

    Explain how Perl is something good to me.......>

    >> Explain how Perl is something good to me.......>

    >
    >
    >Perl is not good for you.
    >
    >Use some other language.
    >
    >Is there a problem?
    robic0, Dec 12, 2005
    #12
  13. John Bokma Guest

    Tad McClellan <> wrote:

    > robic0 <> wrote:
    >
    >> Explain how Perl is something good to me.......>

    >
    >
    > Perl is not good for you.


    Neither is English

    > Use some other language.
    >
    > Is there a problem?


    Has Xah Lee a son, or a sock puppet?

    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    I ploink googlegroups.com :)
    John Bokma, Dec 12, 2005
    #13
  14. robic0 Guest

    On Mon, 12 Dec 2005 09:34:39 -0800, Jim Gibson
    <> wrote:

    >In article <>, robic0 wrote:
    >
    >> On 11 Dec 2005 22:52:07 GMT, John Bokma <> wrote:
    >>

    >
    >[example of map in void context]
    >
    >> >
    >> >Remember, ages ago it was bad to write: for ( 1 .. 10_000_000 )

    >>
    >> What does for(1..$somevariable) actually mean? Is it short for some
    >> C construct?

    >
    >It means a list of values from 1 to the value of $somevariable
    >incremented by 1. See 'perldoc perlop' and search for 'Range'.
    >

    Trust me, I already knew that
    robic0, Dec 17, 2005
    #14
  15. Chris Barts Guest

    Jim Gibson <> wrote on Monday 12 December 2005
    10:27 in comp.lang.perl.misc
    <121220050927296947%>:

    >
    > I would expect that anybody maintaining a program that uses a module
    > such as File::Find would have the intelligence to read the
    > documentation that came with that module.


    Agreed.

    > If they do not, they deserve what they get. It is not up to the original
    > programmer to provide any part of that documentation or even a link to it
    > if it can be accessed in the usual way and the module is being used as
    > documented.


    Again, agreed. But you missed the point he was actually making: The
    Schwartzian Transform is /not/ documented in the usual place, as long as
    that is taken to mean perldoc-accessable files.

    The Schwartzian Transform is unique to the Perl community, and yet it lacks
    documentation in what could be considered Perl's official online (as
    opposed to printed) reference manual. Thus, the considerate (or obsequious)
    programmer cannot point future maintainers to a single document he is sure
    came with their perl distribution and is instead reduced to giving them a
    handful of URLs, one or all of which may be dead by the time the code is
    maintained by anyone else.

    (Oddly enough, the Schwartzian Transform doesn't appear to be in the Third
    Edition Camel, either.)

    --
    My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
    wardsback and translated.
    It's in my header if you need a spoiler.


    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Chris Barts, Dec 18, 2005
    #15
  16. Dr.Ruud Guest

    Dr.Ruud, Dec 18, 2005
    #16
  17. >>>>> "Chris" == Chris Barts <> writes:

    Chris> The Schwartzian Transform is unique to the Perl community,

    Ahem. Can I interject here?

    The ST is a pattern, not a fundamental option or syntax or function call
    or API.

    The perldocs do in fact document everything necessary to use Perl.

    However, just as the dictionaries (and even basic writing primers)
    do not tell you how to write a winning novel, the perldocs are not
    inclusive of what you'll need to write "winning" Perl code.

    There is no inconsistency here.

    And, the ST is also not "unique to the Perl community". I was just
    using patterns I had learned other places to quickly solve a problem
    (as documented in the FMTYEWTK-sorting paper Tom wrote about the
    thing). It's just a tool. Use it, but don't put it on a pedestal. :)

    print "Just another Perl hacker,"; # the original, number 0

    --
    Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
    <> <URL:http://www.stonehenge.com/merlyn/>
    Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
    See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
    Randal L. Schwartz, Dec 18, 2005
    #17
  18. Chris Barts Guest

    Randal L. Schwartz <> wrote on Sunday 18 December 2005
    11:12 in comp.lang.perl.misc <>:

    >>>>>> "Chris" == Chris Barts <> writes:

    >
    > Chris> The Schwartzian Transform is unique to the Perl community,
    >
    > Ahem. Can I interject here?


    :: Awed :: ;)

    >
    > The ST is a pattern, not a fundamental option or syntax or function call
    > or API.


    Obviously.

    >
    > The perldocs do in fact document everything necessary to use Perl.


    Just like a copy of "According to Hoyle" documents everything necessary to
    play poker. There's more to the game than the definition of 'Full House',
    and I think the perldocs should have a bit more of the 'commentary' and
    'oral tradition' than they apparently do now.

    Think of it as a continuum: On one end there's a dry CS text written by and
    for people who think languages are 'incidental' and, at best, minor
    annoyances to people who think in terms of Turing machines or the eternal
    and inviolate lambda calculus. On the other, there's JARGON.TXT, full of
    in-jokes and esoterica more-or-less confined to the single community that
    produced it. The perldocs are always going to sit a lot closer to the CS
    text than JARGON.TXT, but scooching over a bit towards the 'commentary'
    side of things would help people avoid reinventing the square wheel and
    reduce the volume of these threads in Perl groups.

    >
    > However, just as the dictionaries (and even basic writing primers)
    > do not tell you how to write a winning novel, the perldocs are not
    > inclusive of what you'll need to write "winning" Perl code.


    They never can be, but they can include a few things everyone here (using
    'here' in an inclusive, Perl community sense) expects people to know.

    >
    > There is no inconsistency here.
    >
    > And, the ST is also not "unique to the Perl community". I was just
    > using patterns I had learned other places to quickly solve a problem
    > (as documented in the FMTYEWTK-sorting paper Tom wrote about the
    > thing). It's just a tool. Use it, but don't put it on a pedestal. :)


    I wasn't putting it on a pedestal. I was saying that as a *named* *entity*
    it doesn't exist outside the Perl community. In Lisp people do essentially
    the same thing all the time, but they don't call it the 'Schwartzian
    Transform' because that specific concept doesn't exist in the land of the
    lambda.

    (Is it an arbitrary distinction? Tell it to the Gang of Four and all of the
    people who speak pattern languages. Naming things is the basis for abstract
    thought.)

    >
    > print "Just another Perl hacker,"; # the original, number 0
    >


    And probably runs unmodified in Perl1, too.

    --
    My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
    wardsback and translated.
    It's in my header if you need a spoiler.


    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Chris Barts, Dec 19, 2005
    #18
  19. Guest

    John Bokma wrote:
    >
    > Remember, ages ago it was bad to write: for ( 1 .. 10_000_000 )



    Thanks for letting me know. I knew that was bad from reading it in
    the first edition Camel book, and I wondered why it wasn't mentioned in
    the third edition. Now I know why -- apparently "1 .. 10_000_000"
    alone in a for-loop no longer creates an array of ten-million elements.

    -- Jean-Luc
    , Dec 29, 2005
    #19
  20. Guest

    > "" <> wrote:
    >
    > > About my opinion (which says that code not immediately
    > > understandable to a decent programmer should always be
    > > accompanied by documentation (or at least a reference)
    > > that explains the intent of the code)


    A. Sinan Unur replied:
    >
    > I think you are cheating a little here. Your actual stated
    > opinion seems to me that everything that you might ever
    > want to reference should be included in the standard Perl
    > documentation.


    The intent of this thread's original post was that I wanted to know
    of all the perldocs that referenced or explained Schwartzian
    Transforms. (The fact that they were not readily found made me wonder
    if I was searching on the wrong keyword.) But the fact that I want to
    read all the explanations of Schwartzian Transforms that exist in the
    standard perldocs doesn't mean I'm not interested in non-perldoc
    explanations. (It's just that I wanted to be aware of all the perldoc
    ones -- and that the one I did find in perlfaq4 took a while to find.)

    As for referencing the standard Perl documentation over other
    things, I happen to think that, although the perldocs aren't perfect
    (and what is, really?), I think they are *very* good sources of
    information. So good, in fact, that I encourage all Perl programmers
    (beginner and advanced) to use them often, even with small Perl
    questions (and occasionally with some C questions, believe it or not).

    > No one can argue with the proposition that when you
    > do something clever, you should put something that
    > explains where that came from.


    I really wish that were true (that is, that no one can argue with
    it), but I've had plenty arguments about it. I'll find code that
    definitely looks like a bug, but it turns out that this is for a
    special case, which of course isn't documented. When I alert the
    original coder about it, he tells me how any idiot can look at the code
    to see what it's doing (despite the fact that it would require looking
    at a half-a-dozen functions scattered across several files) and resents
    any effort to encourage commenting the intent of that code.

    The big problem is that the coder himself is no moron. In fact, I
    find that very often these types of coders are quite intelligent -- so
    much so that they are unaware of how confusing their code looks to
    "less intelligent" people like myself (or any other person who didn't
    experience the coder's same thoughts that led to the final code).
    Often their response for clarification will be to read the code
    yourself which, I'll admit, works sometimes, but won't help if you
    think you understand (but really don't) or if there is a bug that crept
    in due to a maintainer misunderstanding the code. In cases where bugs
    ARE lurking around, it's difficult to see which part of the code is the
    correct piece and which part is the bug. Because there are no
    accompanying comments, I don't know what the original coder intended
    the correct code to be.

    One of my favorite Perl quotes is this one from p. 129 (in chapter
    10) of "Learning Perl" (3rd edition) by Randal L. Schwartz & Tom
    Phonix:

    "It's important to remember that you're always writing
    code for two readers: the computer that will run the
    code and the human being who has to keep the code working.
    If the human can't understand what you've written, pretty
    soon the computer won't be doing the right thing either."

    Of course, it's not always clear at what point code becomes "clear
    enough." Expert Perl programmers will no doubt understand more
    decently-written Perl code than those just beginning to learn Perl. So
    to be on the safe side, I always encourage people to write their
    comments in such a way so that a maintainer "not quite as intelligent
    as you" can understand it.

    > > As for other programming techniques, algorithms, and idioms that are
    > > not immediately apparent to a maintainer, they don't have to be in
    > > perldocs as long as they are either explained in the form of comments

    >
    > I really don't understand you, I am afraid. Do you propose that what
    > gets included in the standard Perl distribution should depend on what
    > programmers put in their comments?


    No. What I meant was closer to the opposite statement: what gets
    included in programmers' comments should depend on what is included (or
    rather, what isn't included) in the standard Perl distribution (or
    readily available documentation).

    > So, in the case of Schwartzian transform, it should be fine
    > to reference Randal's original article, and move on, instead
    > of insisting that Schwartzian transform should be explained
    > in the standard Perl documentation.


    Yes, provided that Randal's original article is readily available to
    the maintainer. Like I said, I really like perldocs, and one of their
    strengths is that they will always be available, even when certain key
    sites go down. But any referencing of a technique that 50% or more of
    maintainers won't be familiar with is a good practice. And I don't see
    the harm in referencing a website provided that it is reasonable to
    assume that it will always be available to the maintainer when he/she
    needs it.

    > You seem to want to go off on tangents about dimwit
    > programmers who cannot figure out File::Find, or
    > map in void context, or comments.


    Ah, but that's part of my point (and excuse my tangent): the person
    who made that mistake with File::Find was no dimwit. He was a rather
    intelligent programmer who was just new to Perl. He made that mistake
    because he was still somewhat disoriented to the world of Perl.

    I remember when I was new to Perl and I wanted a function that was
    similar to glob() but worked recursively. From "Learning Perl" I knew
    to use the File::Find module, but when I read its perldoc, I was very
    confused. The reason? I was disoriented due to the fact that I was
    expecting to find a function that could be used like:

    my @listOfFiles = recursiveFind($topLevelDir);

    but instead found File::Find::find() which worked in a way that was
    very unfamiliar to me. (And I'm not saying that File::Find::find() is
    a bad function (after all, it is a lot more flexible that the
    hypothetical recursiveFind() function), but I am saying that it's not
    what people unfamiliar with recursive file finding in Perl are
    expecting to find. Therefore, they might not even realize that it's
    recursive, which was how the programmer I mentioned earlier made that
    particular mistake with File::Find. It's not that he was a "dimwit";
    it's just that I forgot my own confusion that I experienced when I
    first read about it, and never even considered that future maintainers
    might experience the same confusion that I initially had with
    File::Find. I assumed that since I knew how to use it everybody else
    should, especially if they're smart enough to read "perldoc
    File::Find".)

    > The issues you raise are all valid,
    > but irrelevant to the question I asked.
    > For the record, that question was:
    > "Does the explanation of the "Schwartzian Transform"
    > -- a general algorithm -- need to be included with Perl?"


    Sorry -- as you probably already noticed, I sometimes go off on
    tangents. But back to your question... and here's your answer:

    I'm not sure if it "needs" to be included in the standard perldocs,
    but it sure would be nice to have.

    One final thing: The standard perldocs are authoritative: if the
    perldocs condone something, decent Perl programmers will be more likely
    to study it and make an effort to understand it. And if the
    Schwartzian Transform is included, decent programmers will less likely
    dismiss it as if it were just another hard-to-understand piece of
    "hack" code.

    > Aaaanyway, I am probably becoming too pedantic, so I'll stop now.


    Yeah... I'm guilty of that, too. :)

    Take care,

    -- Jean-Luc
    , Dec 29, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David Di Biase

    Re: Schwartzian transform for tuple in list

    David Di Biase, Sep 24, 2008, in forum: Python
    Replies:
    5
    Views:
    251
    Steven D'Aprano
    Sep 25, 2008
  2. wana

    best way to search perldocs

    wana, Sep 27, 2004, in forum: Perl Misc
    Replies:
    7
    Views:
    96
    Tad McClellan
    Sep 28, 2004
  3. Replies:
    0
    Views:
    90
  4. William James

    Schwartzian Transform built-in to Perl 6?

    William James, Aug 28, 2005, in forum: Perl Misc
    Replies:
    0
    Views:
    99
    William James
    Aug 28, 2005
  5. Jorge

    Numerical sort (Schwartzian xform)

    Jorge, Sep 6, 2006, in forum: Perl Misc
    Replies:
    16
    Views:
    178
    Tad McClellan
    Sep 8, 2006
Loading...

Share This Page