Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Monk ethics: Beauty vs. Power

by kaatunut (Scribe)
on Dec 18, 2000 at 21:28 UTC ( [id://47213] : perlmeditation . print w/replies, xml ) Need Help??

Even though I am merely an Adept or so, already the beauty of code is something to strive for, to me. When moved from BASIC (shudder) to C, I was stunned by the seemingly magical expression wizardry of C (hey, after BASIC...). To think that you could do entire loop's job inside while() ! It eased up a bit, the joy of game diminishing, and soon I was again wading in the bore of function/class structures.

But THEN, then I learned perl. At first I wrote it almost like C (look at E2 node tracker to see what I mean...), but as time passed I started to slowly learn a bit stranger magic. Now, as I just wrote some rather peculiar (well, to me) expression, something struck me:


Is a monk's ethos (?) to create working code, or to create beautiful code (when they do not coincide)? Is the purpose of perl to create code quick, or to give the pleasure of expression meditation to the coder?

I realize that often beautiful code IS better code, efficient- or reusability-wise. But is it always? What to do if, no matter how bad it looks, a code is tad more efficient? And isn't it a bit, um, counter-productive to spend your time thinning out a block of code when you could be creating new?

P.S. My idea of 'beautiful' is influenced by my recent learning of perl and might not match yours. Still, I can't help but to observe that typical perl code *does* make use of strange chains in one expression as opposed to C-style procedures.


Replies are listed 'Best First'.
Re: Monk ethics: Beauty vs. Power
by Dominus (Parson) on Dec 18, 2000 at 21:49 UTC
    It depends on what's needful. Sometimes the right thing to do is to hack out the thing that works, as quickly as possible. Sometimes the right thing to do is to work carefully on the design. Other times you need the fastest possible code, and then you don't use Perl.

    We live in a world. Programming is part of that world. It doesn't make sense to ask what a monk 'should' do except in relation to the rest of the world.

    No 'ethos' is better than the others. All have their places.

      I would disagree on one point. No ethos is better than all others. But some are clearly worse.

      In general it is safe to say that adjusting your policy to the need is a good idea. In my experience it has been true that if you worry about how to make things easy to debug and easy to change later, that usually works out pretty well.

        No ethos is better than all others. But some are clearly worse.

        Can you give some examples? I can't say I have a particular ethos as such, but I can't really think of a "distinctive spirit" (see that people have in regards to programming that I would consider bad. Even not having any particular approach isn't such a bad thing IMHO; it just means you haven't formed a general view as such yet.

Re: Monk ethics: Beauty vs. Power
by footpad (Abbot) on Dec 19, 2000 at 00:23 UTC
    Except for education (whether formal or personal improvement), programming generally occurs in a business context. It's an action designed to solve a business need and, at some level, help the organization generate more profit.

    With this in mind, I generally consider code to be beautiful, powerful, and ethical if the:

    • Project's sponsor is happy with the results (e.g. the client is willing to pay the bills).

    • The end-users are happy with the results.

    • Source code can be easily maintained by someone having a more limited understanding of the business or the implementing language. (This means a) comments, b) organization, and c) consistent formatting.)

    • Results work as intended, meaning no outstanding bugs or related problems.

    • Results reasonably meet the requirements (specification and schedule).

    • Final implementation (or elements thereof) lends itself to re-use in other, similar projects.

    • Source follows community accepted "best practices" (aka "elegance") to achieve its goals.

    This means that most of the time, I'm trying to produce working code, not elegant code.

    You'll note that I rate maintainability higher than elegance. As someone who's inherited many projects over the course of my programming career, I have seen good code that was poorly documented and bad code written very clearly. In nearly every case, I have preferred the latter because "elegant" code can require more knowledge regarding the language, system, and environment than the client has been willing to pay for me to learn.

    As Dominus said, it really depends. Look at your overall schedule and see what needs to be accomplished in that time frame. Figure out the tasks, determine your knowledge of how to achieve those tasks, and then budget your time appropriately....even if it means you may make an mistake in your initial design.


Re: Monk ethics: Beauty vs. Power
by mrmick (Curate) on Dec 18, 2000 at 21:37 UTC
    Personally, I tend to lean towards creating 'working' code as opposed to 'beautiful' code. Often, it just happens to be beautiful because of the way we think when programming in Perl. I think this may have something to do with a linguist having developed the language and the community standing by and supporting an easy-to-use programming environment.
    my environment = core language + modules;

Re: Monk ethics: Beauty vs. Power
by royalanjr (Chaplain) on Dec 18, 2000 at 21:38 UTC

    To a small extent, beauty is in the eyes of the beholder. With TIMTOWTDI, and "do the right thing" there is a lot of latitude.

    Something that I write, that works, and that I think looks beautiful might be an abomination to the great merlyn.

    Roy Alan

Re: Monk ethics: Beauty vs. Power
by InfiniteSilence (Curate) on Dec 19, 2000 at 00:27 UTC
    Here is an excerpt from a note in my journal on 'Programming as Art':

    Is it so strange to seek eloquence and imagination within one's life work?

    To summarize, I think it is an internal drive toward self expression to form something from nothing. Since thought is, for the most part, fluid, the expression of that thought can likewise be fluid. Hence, rethinking a piece of code outwardly mimics the natural internal process. Only difference is that here it is a part of the culture to express it.

    Celebrate Intellectual Diversity

Re: Monk ethics: Beauty vs. Power
by lemming (Priest) on Dec 19, 2000 at 00:27 UTC

    For code that others may see, beautiful code is something that is easy to read to me. As a goal I prefer self documenting code, but if there is a trick then comments are necassary.

    If it's something I banged out in an afternoon and may never use again; Whatever works. If something new was discovered or it's a neat bit of code; I tend to save those off to the side for incorporation elsewhere. They get cleaned up before hand.

    Short description: If I can read it, it's beauty. If I look at my code later and go "What the hell!?", that's ugly

    And obsuscation is beauty of a different type.
Re: Monk ethics: Beauty vs. Power
by Trimbach (Curate) on Dec 19, 2000 at 02:59 UTC
    It amuses me greatly to see everyone flailing about as to what defines "beautiful" Perl code... it is not unlike the thrashing that people go through defining what "real" beauty is in regards to people, art, cars, sunsets, home runs, etc. etc. etc.

    The lesson here is that code CAN be beautiful, and beautiful in the same exact way as all those other things. The rules of the game are the same, and who here can define a beautiful sunset?

    As our friend Keats once said:

    "Beauty is truth, truth beauty,"--that is all
    Ye know on earth, and all ye need to know.

    Gary Blackburn
    Trained Killer

Re: Monk ethics: Beauty vs. Power
by Fastolfe (Vicar) on Dec 19, 2000 at 08:12 UTC
    In my experience, as I've bettered my skills in Perl, I find that beautiful code is code that is efficient and elegant. The better a person tends to be at figuring out the best approach to a problem, the better that person tends to associate beauty and art in code with the skill and elegance involved in crafting it.

    How many times have you seen a small snippet of code and thought to yourself, "Fuck, man, that's beautiful."?

    Naturally there's going to be exceptions; nobody is a perfect coder, but I suspect this subconscious tendency only grows more accurate the better your skills are with a language.

Re: Beauty vs. Power
by ichimunki (Priest) on Dec 19, 2000 at 02:23 UTC
    I'm hardly an authority, but I have been attempting to learn to program computers since the fourth grade (I'm over 30 now). It seems to me that beautiful code is that which is powerful and vice versa. Ugly code is illegible, difficult to maintain, and therefore prone to error. Pretty code (in terms of consistent formatting, consistent algorithms, and efficient structure) is usually quite legible, easier to maintain, and less prone to error.

    Whenever I feel like I'm hacking away at a problem instead of hacking a solution, I try to remember the three virtues. Will this code be reusable and maintainable, is it efficient, and is it just plain cool? I think a lot of the "software sucks" mentality would go away if more of us worked at these things. Programming is habit forming, and I'd rather have good habits than bad.
Re: Monk ethics: Beauty vs. Power
by elusion (Curate) on Dec 19, 2000 at 00:07 UTC
    For me, working code is more important. There a lots of people, like me, who aren't experts, and sometimes even working code is hard to come up with. There is a thing to be said for beauty, however, and if I write a script that I am constantly changing/using, I'll redo it to make it beautiful.

    - p u n k k i d
    "Reality is merely an illusion, albeit a very persistent one." -Albert Einstein