Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Tao Perl Ching - The Scripture of the Way of Perl

by radiantmatrix (Parson)
on Dec 17, 2004 at 18:52 UTC ( [id://415740]=perlmeditation: print w/replies, xml ) Need Help??

This node has been updated twice since its origninal incarnation

I read the WikiPedia's article on Tao Te Ching, which contains a summary of some of the principles in that text. As I've studied the ideas in the TTC for some time, I found the summary interesting, but disagreed with some of it. In pondering the summary, I realized that many of the principles align well with principles of good Perl development (and most apply to development in general).

Computing is a relatively new field, and so many new theories and philosophies have popped up to explain and guide the development process. Most of them are even pretty good. But, my own personal experiences have shown that while new ideas are often good, one throws out old ideas at one's own peril. Thus, I think it's fascinating to note how very old priniciples contained in a very old text apply so well to a very new pursuit.

In reading some of the responses to the first, hasty rendition of this node, I came to realize that it would be best to use my own interpretations of the principles I found listed in the WikiPedia article. However, just because I believe these to be valid doesn't mean I think that no one else is right, that I'm neccessarily more wise than anyone, or that my ideas about them will never change. See the link in my signature. ;-)


  • Force causes resistance
    When promoting Perl or one of its many ways to do things, it is important to remember that forcing something to be the way you want it will often result in resistance. This applies to people as well as to code. If you try to get Perl mandated in an all-VB shop, the resistance will be overwhelming. If you try to force-fit a solution to a problem, you will be forced to live with the limitations you have created for yourself. In any case, forcing something usually just makes things more difficult.

  • One whose needs are simple will find them fulfilled
    One of the tenets of successful design is to redefine problems to make them more simple -- or even so that they go away. By realizing all that you don't require, your project is more likely to find success. This is in harmony with the tenet of "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupery)Thanks, poqui!

  • Wealth does not enrich the spirit
    Good code is its own reward; people who code only because they are getting paid to do so will never be truly excellent coders. Enlightenment comes from the desire to do well for its own sake.

  • Self-absorbtion and self-importance are vain and self-destructive
    Not only does this apply to making your code maintainable, writing and publishing your code as modules, and so on; it also applies to avoiding the stubborn refusal to believe that someone else might be right. Good developers are back up their opinions with facts, and are willing to learn from both the more-experienced and the less-experienced.

  • Victory in war is not glorious and not to be celebrated, but stems from devastation, and is to be mourned
    Flamewars have no real "winners", nor to "holy wars" over editors, favorite modules, languages, etc. Flexibility and the ability to compromise are more valuable than the ability to brute-force things.

  • The harder one tries, the more resistance one will create for oneself
    This has a lot to do with acknowledging limititations and working with them and around them, rather than trying to force a system to do that which it was not designed for. This applies to methodology as well -- reinventing the wheel (trying hard) only makes things more difficult than, for example, living with an existing wheel that isn't as pretty as you'd like. This is nearly a repeat of "Force causes resistance".

  • The more one acts in harmony with the way things are, the more one will achieve, with less effort
    This could easily be restated as "CPAN exists for a reason, the more one uses it, the more one will achieve, with less effort." It also applies to using existing standards, rather than inventing one's own (unless the standards don't fit).

  • The truly wise make little of their own wisdom — for the more they know, the more they realize how little they know
    Good Perl coders, too, are loathe to say that a method is the best or only way to accomplish something. The better one becomes with Perl, the more one realizes that there is a lot left to learn. Even TimToady, for example, is quick to note that he does not know everything about every quirk.

  • When we lose the fundamentals, we supplant them with increasingly inferior values which we pretend are the true values
    This happens all the time in the coding world. New techniques come about, and people latch onto them while ignoring the fundamental principles of good code. OO is a great example of this -- some people latch onto OO as though it were the only "good" way to look at any problem. Perl has nicely avoided these sticky wickets by supplying options: you can use OO, or not. You can implement strong(er) typing, or not.

  • Stupidity causes one to take the path of most resistance
    Refusal to use a perfectly good extant module leads to bad code. Failing to research what is available, and consider the best way to approach the problem may be leads to code that simply attacks the problem. Elegant solutions are better. Witness the examples of people who wish to handle all of CGI with one regex, rather than using something like CGI or CGI::Simple -- invariably, they end up finding out that CGI is more complicated than they thought, and either use a module or end up rewriting all of an existing module's functionalty. Poorly.

  • The wise are responsible for the foolish
    The more experienced PerlMonks should (and do) try to help the newbies. The community is only as strong as its weakest members, so those that are stronger would be wise to help those that are weaker.

  • The honest are responsible for the dishonest
    This applies a great deal to tainting and security considerations. Never assume that someone else's code was designed to be anything less than a back door, and plan accordingly. It's ultimately the programmer's job to ensure that the final product works, regardless of what code it must interact with.

  • Glorification of wealth, power and beauty beget crime, envy and shame
    So many commercially-developed applications -- and even languages -- have become so obsessed with the "bling" of fancy IDEs, buzzword-compliance, and slick marketing. Perl is concerned with function and flexibility, which is a wise course. Developers are wise not to put so much emphasis on snazz that function suffers -- most of us have been on projects where the opposite was true, and do they ever turn out well?

  • The excercise of flexibility and suppleness is often superior to brute strength and rigidity
    TMOWTDI. Flexible code, that which is easy to extend, modify, and modularize, is nearly always the best code. That said, use strict is still a good idea. "Suppleness" can be taken to be "fault tolerance" -- code should not fail loudly when it encounters a tiny error. Being willing to alter one's views and adapt to new situations is more likely to succeed than blindly insisting on a particular approach.

  • Everything in its own time and place
    Perl 6 development embodies this, as does most of the F/OSS community. Things will be done when they are ready to be done. This also works with the development cycle -- don't spend your time designing fancy GUIs until your core logic works, for example.

Replies are listed 'Best First'.
Re: Tao Perl Ching - The Scripture of the Way of Perl
by Juerd (Abbot) on Dec 18, 2004 at 00:41 UTC

    Refusal to use CGI.pm leads to bad code.

    Thanks.

    I think CGI.pm is a big, ugly monster that should only be used when needed, and even then only for what this module does more than others. There's a lot in its source that makes me think Mr Stein never really bothered to learn (modern) Perl, but the easiest to find and refer to weirdness is "/gso". Apart from the somewhat weird code, CGI.pm is huge, inefficient and does things that shouldn't be in a CGI module, like generate HTML (HTML exists outside CGI, CGI can be useful without HTML. They have no close relationship).

    Fortunately, there are CGI::Lite, CGI::Simple, and others. The latter unfortunately is interface-wise compatible with CGI; and I don't like that interface much.

    I refuse to use CGI.pm in almost every situation. Does that make my code bad?

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      I have not studied CGI.pm in great enough depth to evaluate your crticisms, though they seem legitimate. However, what I have seen a lot of in my time here (including two years lurking before signing up) is a long stream of Monks who were unaware of CGI.pm or thought they didn't need it, and instead believed incorrectly that they could parse query strings, interpret application/x-www-form-urlencoded and multipart/form-data POST submissions, and parse or create cookies on their own using only regexes and Perl's builtin operators. These things can be done, but doing them right is harder than these people realized. There are a few problems with this:

      1. As a general matter, application developers should not have to worry about the implementation details of the protocols and calling conventions they use. This is what APIs are for.
      2. Failing to properly treat these kinds of inputs can likely lead to security problems.
      3. All developers should learn the habit of looking whether the problem they're trying to solve has been solved before in a way that they can reuse. People who try to read web forms or cookies by hand are likely not to be following this rule in other regards as well. This is Laziness in the good sense.

      So if the issue is that people are using the wrong module, you may be right. But the bigger issue is people who are unaware of/refuse to use the excellent modules at their disposal.

        You are absolutely right. However, the root post explicitly mentioned "CGI.pm", and not "the excellent modules at their disposal", and my rant is about just that: CGI.pm has a status it (IMO) no longer deserves.

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      There's a lot in its source that makes me think Mr Stein never really bothered to learn (modern) Perl, but the easiest to find and refer to weirdness is "/gso"

      Which, conveniently, occurs right next to my favorite line in CGI.pm, 2124:

      # hack to work around earlier hacks

      That said, my first reaction to the root node was: "Great. Another Soccer-Mom Node." Honestly, I've been a regular at this site for almost 3 and a half years, and really-syrupy-sermony still bothers me. From the "COME BROTHERS, LETS BASK IN THE GLORIOUS LIGHT THAT IS PERL!" style nodes to the "HUGE PEDANTIC NODE WITH A CONTROVERSIAL TITLE THAT IS ACTUALLY ABOUT AN ISSUE THAT IS OBVIOUS AND YOU PROBABLY KNOW ABOUT ANYWAY" style, I still can't keep myself from rolling my eyes and Crl-W-ing my browser tab about a paragraph into the node. The node might even have some sort of topic I might have been interested in reading otherwise, but the tone completely drives me off before I even get that far. I wonder: is it because this website has "Monastery" in the name? Would these same nodes have been written if we were http://www.perlclub.com, The Perl Clubhouse? Anyways, I needed to get that off my chest.

      At any rate, who uses CGI these days anyway? ;)

        I decided to post this node for a few reasons. Firstly, there have been a number of nodes talking about how Perl relates to other pursuits -- many of which are considered noble or philosophical. Throughout my life and career, I have found that far too much emphasis is placed on "this new, insightful way of thinking". So, my first intent was to illustrate that very old ideas can still apply to very modern pursuits.

        Secondly, I've studied the Tao Te Ching for a good chunk of my life; I've applied my own interpretation of it to my system designs -- and while I still have much to learn about software design (and Perl), I feel that applying it has made me a better developer.

        Thirdly, part of my job is training others. The day will come when I will have to train a department on solid coding practices. Having "gimmicks" like this that help teach and help students retain is useful. I hope to refine the analogy through discussion.

        And, finally, I find it fun and useful to put my ideas onto a forum to have them picked apart. Maybe it doesn't teach me Perl, but since a node like this contains bias resulting from my personal outlook, I have found that I am able to find flaws in my outlook through discussing it.

        As for the last line, I use CGI on a regular basis, and a lot of people still use it for simple web applications. It hasn't outlived its usefulness, yet. ;-)

        radiantmatrix
        require General::Disclaimer;
        s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}

      The latter unfortunately is interface-wise compatible with CGI; and I don't like that interface much

      Why is that? Not to troll, I'm just curious. Personally I only use CGI::Simple + HTML::Template which is about 50% faster than useing CGI.pm in most of my circumstances.

        Why [do you not like CGI.pm's interface much]?

        Mostly because it's terribly inconsistent. Why is is Vars ucfirst, but param all lc? Why are some, but not all words in names separated by underscores? Another thing I absolutely do not like is the prefixed minus for arguments. Perl is not a shell, so stop trying to look like one. And even then: no, that minus doesn't make it look like shell command line arguments. Of course, the minuses are needed because CGI.pm mixes positional and named arguments.

        Yes, CGI::Simple is much faster than CGI.pm. And that's a good reason to use it. I use it often. Doesn't mean I like the interface. I understand that it wants to be compatible with CGI.pm.

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      I agree that CGI.pm is generally not the best CGI module. But its main advantage is that comes pre-installed on the system because it is a core module. Sadly, it has a lot of historical cruft that has to be kept for backwards compatibility. As for it not being "modern" I suspect it is because it was originally written a very long time ago.

        I agree that CGI.pm is generally not the best CGI module. But its main advantage is that comes pre-installed on the system because it is a core module.

        I prefer to call that "standard module" and call modules that enable core functionality "core modules", like strict, warnings and File::Glob.

        Anyway, it's not hard to deal with both, as interfaces are compatible:

        # Fall back to CGI.pm if CGI::Simple is unavailable. # We prefer CGI::Simple because it much lighter and faster. my $cgi = eval { require CGI::Simple; CGI::Simple->new } || do { require CGI; CGI ->new };
        I do think avoiding CPAN modules is a bad idea.

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      Well, you don't refuse to use an already-extant CGI module, which is really what I meant. When I figure out a good and quippy way to say that, I will make an update to the node.

      radiantmatrix
      require General::Disclaimer;
      s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}

        Well, you don't refuse to use an already-extant CGI module, which is really what I meant.

        Say what you mean. It's easy and prevents a lot of trouble.

        When I figure out a good and quippy way to say that, I will make an update to the node.

        How about "a CGI module" instead of explicitly "CGI.pm"?

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Re: Tao Perl Ching - The Scripture of the Way of Perl
by Stevie-O (Friar) on Dec 17, 2004 at 22:05 UTC
    Since nobody has replied, I'll start things off with a real-life example that fits your statements (even though it has little to do with Perl, beyond my use of it for log analysis purposes) -- perhaps others will then share their experiences:

    "The harder one tries, the more resistance one will create for oneself."


    I work on a small device that connects to cash registers & vending machines, and allows payment to be made via RFID keychain tags. The devices communicate to our system over the Internet. They first go through a router (called a 'gate') that serves basically as a NAT bridge between their proprietary wireless radios and a ethernet/modem uplink.

    --Stevie-O
    $"=$,,$_=q>|\p4<6 8p<M/_|<('=> .q>.<4-KI<l|2$<6%s!<qn#F<>;$, .=pack'N*',"@{[unpack'C*',$_] }"for split/</;$_=$,,y[A-Z a-z] {}cd;print lc
Re: Tao Perl Ching - The Scripture of the Way of Perl
by apotheon (Deacon) on Dec 18, 2004 at 03:29 UTC

    I need to go edit that entry at Wikipedia. There are two common misconceptions (by my interpretation) of the Tao Te Ching in that list.

    One is in the statement "Self-interest and self-importance are vain and self-destructive." That should be "Self-importance is vain and self-destructive." Self-interest isn't either of the above except when misused. Of course, altruism can be vain and self-destructive as well and, in fact, might be thought as self-destructive by definition. Ayn Rand certainly thought of it that way, and it's awfully difficult to find fault with that particular part of her overall belief system.

    The other is the statement that "feminine" qualities are "superior" to "masculine" properties, which is actually quite antithetical to some of the core wisdom of the Tao Te Ching. The very next statement in that list, "Everything in its own time and place," helps to make that clear, I think.

    I currently own three copies of the Tao Te Ching, each being a different translation than the other two, and have read it in various translations several times. If pressed to label myself in terms of my metaphysical philosophy, I'd call myself a Taoist. I find such (accidental, I'm sure) misrepresentations of the wisdom of the Tao to be so prevalent is disappointing, though understandable in the context of post-modern Western value systems, which prevail in many universities in the US.

    print substr("Just another Perl hacker", 0, -2);
    - apotheon
    CopyWrite Chad Perrin

      Yes, I agree that they were not the most well-phrased. But I didn't want to start a debate about my particular interpretations, so I just quoted someone else's that were fairly close.

      Self-interest should be, in my opinion "self-absorbtion".

      As far as "feminine" and "masculine"; as a 6'1" male who takes pride in his ability to embroider, I've always eschewed the labels of "feminine" and "masculine". I think the interpreter here took the analogy of Yin/Yang to Male/Female a bit too literally, which is all too common. As for the rest of the statement, I would personally say that the properties of flexibility and suppleness are at least as important as the others. To suggest that one quality is more important than another somewhat ignores the concepts of contrast and balance in the TTC.

      But, all of that is waaay off-topic. More to the point, do you think the node would be better served if I just used my own versions of the priciples and ignored the WikiPedia article?

      radiantmatrix
      require General::Disclaimer;
      s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}

        Ooh! "Self-absorption" is great! I should have waited on this response before I edited the Wikipedia entry. I'll just have to go add that in now.

        My point in regards to the contrast of "feminine" qualities and "masculine" qualities is actually based in the equal status of yin and yang in Chinese philosophy. Neither is "better" or "more important" than the other. They are different, and they are equal. One is more applicable in some circumstances, and the other is more applicable in other circumstances. I didn't like the suggestion that one should eschew yang for the sake of yin.

        Considering that I'm engaged in editing the list in the Wikipedia article, you could probably just requote it, edit your node appropriately, and be done. If you have problems with my take on the interpretations, you can even re-edit the Wikipedia entry to suit yourself. That's the great thing about wiki sites. Who says you have to choose between the Wikipedia list and your own list of interpretations? Heh.

        I'm sure there's some Taoist moral to be learned from this, but I'm not feeling sufficiently poetic right now to formulate it in English.

        print substr("Just another Perl hacker", 0, -2);
        - apotheon
        CopyWrite Chad Perrin

Re: Tao Perl Ching - The Scripture of the Way of Perl
by tilly (Archbishop) on Dec 18, 2004 at 04:05 UTC
    In attempting to make much of the wisdom we possess, we demonstrate ourselves to not be truly wise. Having lost sight of the fundamentals, our understanding of the words of wisdom becomes an understanding of inferior values which we pretend are the true values.

    Yet the tao remains as the tao was - a prescription for how to live our lives. Accept its rhythms, discard rigid preconceptions for the readiness to accept what comes, and that which needs to happen will happen in its own time and place. Without apparent effort.

Re: Tao Perl Ching - The Scripture of the Way of Perl
by chanio (Priest) on Dec 18, 2004 at 19:26 UTC

    ...The more one acts in harmony with the universe (the Mother of the ten thousand things), the more one will achieve, with less effort

    This could easily be restated as "CPAN exists for a reason, the more o +ne uses it, the more one will achieve, with less effort..."

    Following the idea of CPAN as a universe, I would like to add that when presenting a new CPAN module one should be aware that not only are we adding another useful tool, but also a level of confusion to the whole. So one should study where is the best place to add the module. And what is the better way of calling it. To make CPAN the most user friendly as possible.

    Besides, about the 'Feminine' as being better that 'Masculine' I remember arguing with some very clever girls because of the oposite concept. It is very difficult for the Occidental thinking to accept that Oriental women are not underestimated. It is very difficult for us occidentals to get rid of the idea of superiority as being someone always over another one. So, I would also underline the possitive feminine concepts found in the Tao Te Ching for us Occidentals to understand it better.Our concept of submision is very poorly developed, yet compared with the oriental one.

    Tao Te Ching is mainly poetry. And as the legend says it was written in a hurry because wise Lao Tzu was trying to leave his country after writing his book as requested by the frontier officer. Compare this with the occidental books that where written during a life of sacrifice, and obsesions...

    .{\('v')/}
    _`(___)' __________________________
    Wherever I lay my KNOPPIX disk, a new FREE LINUX nation could be established.
Re: Tao Perl Ching - The Scripture of the Way of Perl
by BrowserUk (Patriarch) on Dec 18, 2004 at 10:53 UTC

    I often wonder if there are large numbers of modern orientals that find near magical significance in the writings of early western philosophers?


    Examine what is said, not who speaks.        The end of an era!
    "But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
    "Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

      Near-magical significance, I like that. ;-) Part of the reason that early Eastern philosophers are admired in the west, but not vice-versa, is because the early Eastern philosophers were philosophizing long before there was a civilized West.

      As for the "near magical significance" bit, the assumptions work both ways. Many people do assume that eastern philosophy is the answer to all: but it seems that you assume that anyone who studies and admires such philosophies is one of the former. Both assumptions are inaccurate.

      radiantmatrix
      require General::Disclaimer;
      s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}

        ...the early Eastern philosophers were philosophizing long before there was a civilized West.

        Perhaps, but your case isn't helped by the fact that the classical period of Chinese philosophy was about the same time as the classical period Western philosophy, i.e. approx. 700 - 0 BCE. The Tao Te Ching itself is probably no older than ~400 BCE.

        We're building the house of the future together.
Re: Tao Perl Ching - The Scripture of the Way of Perl
by zentara (Archbishop) on Dec 18, 2004 at 11:44 UTC
    Nice thoughts about Tao. But when things get tough on the earth-plane, you shouldn't
    use Tao;
    instead transcend, and

    use Om;.

    ....and sleep better at night. :-) Remember, at some point we all have to leave this all behind.


    I'm not really a human, but I play one on earth. flash japh

      Interesting advice. I find that the Tao and Om modules are both quite useful, and not wholly incompatible, as long as you understand the difference in interfaces where they overlap.

      radiantmatrix
      require General::Disclaimer;
      s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}

        This may be getting OT, but the biggest difference I see, between the Tao and Om modules, is that the Tao focuses on the sexual nature of existence(yin-yan), whearas yin and yan are unified, and undifferentiated in the Om module, where there is no $sex variable. $Psychoanalists->freak_out. :-)

        I'm not really a human, but I play one on earth. flash japh
Re: Tao Perl Ching - The Scripture of the Way of Perl
by Anonymous Monk on Dec 18, 2004 at 05:34 UTC
    What pretentious doggrel! PU!
Re: Tao Perl Ching - The Scripture of the Way of Perl
by poqui (Deacon) on Dec 20, 2004 at 18:05 UTC
    "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupery
Re: Tao Perl Ching - The Scripture of the Way of Perl
by Mago (Parson) on Dec 21, 2004 at 14:10 UTC
    Tao Te Ching - Lao Tze

    "The Tao that can be told is not the eternal Tao.
    The name that can be named is not the eternal name.

    The nameless is the beginning of heaven and Earth.
    The named is the mother of the ten thousand things.

    Ever desireless, one can see the mystery.
    Ever desiring, one sees the manifestations.

    These two spring from the same source but differ in name; this appears as darkness.

    Darkness within darkness.
    The gate to all mystery."


    "A good walker leaves no tracks;
    A good speaker makes no slips;
    A good reckoner needs no tally.
    A good door needs no lock,
    Yet no one can open it.
    Good binding requires no knots,
    Yet no one can loosen it.

    Therefore the sage takes care of all men
    And abandons no one.
    He takes care of all things
    And abandons nothing.

    This is called "following the light."

    What is a good man?
    A teacher of a bad man.
    What is a bad man?
    A good man's charge.
    If the teacher is not respected,
    And the student not cared for,
    Confusion will arise, however clever one is.
    This is the crux of mystery."


    "Between birth and death,
    Three in ten are followers of life,
    Three in ten are followers of death,
    And men just passing from birth to death also number three in ten.
    Why is this so?Between birth and death,
    Three in ten are followers of life,
    Three in ten are followers of death,
    And men just passing from birth to death also number three in ten.
    Why is this so?
    Because they live their lives on the gross level.

    He who knows how to live can walk abroad
    Without fear of rhinoceros or tiger.
    He will not be wounded in battle.
    For in him rhinoceroses can find no place to thrust their horn,
    Tigers no place to use their claws,
    And weapons no place to pierce.
    Why is this so?
    Because he has no place for death to enter.
    Because they live their lives on the gross level.

    He who knows how to live can walk abroad
    Without fear of rhinoceros or tiger.
    He will not be wounded in battle.
    For in him rhinoceroses can find no place to thrust their horn,
    Tigers no place to use their claws,
    And weapons no place to pierce.
    Why is this so?
    Because he has no place for death to enter."


    Perl is YANG

    Yang is the strong, male, creative, giving force, which is associated with heaven. The heaven above us is always in motion and brings about change. Yang is associated with the following ideas and things:

    - Day, Light
    - Sunshine, Fire, Heat
    - Summer, Spring
    - Even Numbers
    - The Sun
    - South, East
    - Left, Up
    - Intellect
    - Active, Dynamic
    - Expansion, Increasing
    - Innovative, Reformative
    - Mountain
    - Desert
    - Straight Line
    - Dissolving
    - Physical (Observable) World
    - Tiger
    - Bladder, Intestines, Skin


    Mago
    mago@rio.pm.org
    Taoist Student

      Which translation is that? I'm somewhat familiar with the Ralph Alan Dale, Stephen Mitchell, and Thomas Cleary translations, but I don't think yours matches any of these. I'd like to know whose translation it is, if you don't mind.

      I disagree, though, that Perl is necessarily of Yang nature. A Perl script can be overly balanced toward either Yin or Yang, depending on how it is written, and given applications of Perl to various problems can be Yin or Yang in nature, but Perl itself seems neither Yin nor Yang inherently. For each of the items you listed, presumably as demonstrations of the Yang nature of Perl, a counter-example could also be offered to make a case for the Yin nature of Perl.

      Rather than say that Perl is Yang, I think it might be more accurate to say that Perl is of the Tao, just as everything else is, and that it thus embodies and encompasses, and is embodied and encompassed by, both Yin and Yang, as well as embodying and encompassing the balance between them and being embodied and encompassed by it.

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin


        The Perl is Yang !

        The Progammer is Yin !

        The union is Tao (the equilibrium between yang and yin).

        Mago
        mago@rio.pm.org


        Which translation is that?

        I believe it's the "Jane English" translation. It's a very popular edition with complimentary brush-art.



        Wait! This isn't a Parachute, this is a Backpack!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://415740]
Approved by dragonchild
Front-paged by TStanley
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2024-03-28 09:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found