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.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
|
