First of all, I'd like to point out that I'm a big fan of simplicity. I've often found myself fighting with others because they want to create a solution that involves so much overkill that they'll spend countless hours developing cool code that will never be used. That drives me nuts. However, in your post, you quoted:

Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Frankly, that almost made me gag. In my book, your code should be three things: complete, concise, and consistent (also known as the 3 C's). I think that if you put all three of these elements together, you'll end up with code that is "simple." You may not see this as "elegant," but I think most programmers have very different opinions of exactly what elegant is.

For example, I was working on a project that had some very complex data structures. I like to encapsulate my data into objects that make sense. On this project however, this left me with level after level of data that I needed to sift through in order to make the object that I was constructing function the way I wanted it to. In that aspect, I'd say that what I was creating was very inelegant. However, the user interface to my class worked beautifully. Because I had put so much work into the back end of the object, the user could access data quickly and easily. Mark one up for simplicity and elegance in that case.

So, I guess it's hard to say what's elegant and what's not. In my situation two parts of the same object were very different when it came to how elegant I thought they were. (I'm sure others might disagree with me about the level of elegance.) However, I can strongly say that the entire object that I had constructed was complete, concise, and consistent. I don't think you should ever sacrifice any of these, even for one of the others - they should all work together to give you a simple, and hopefully, elegant, piece of code.

- Sherlock

Skepticism is the source of knowledge as much as knowledge is the source of skepticism.

In reply to Re: The qq{worse is better} approach (discussion) by Sherlock
in thread The qq{worse is better} approach (discussion) by deprecated

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.