http://qs321.pair.com?node_id=442470


in reply to Beautiful Perl

Beauty is for the unemployed.

Replies are listed 'Best First'.
Re^2: Beautiful Perl
by cog (Parson) on Mar 26, 2005 at 12:56 UTC
    I disagree. Try maintaining code which is bad for eyes and you'll see what I mean.

    And it's not a matter of spending more time coding because you're "beutifying" what you write. Don't tell me it is, because it ain't.

    You actually save coding time if you write it properly; otherwise, by line 20 or so you'll be wondering what the name of that variable was and you'll have a hard time finding it.

      Is beauty really just that which does not cause pain to look at ("bad for the eyes") or that reaches some minimum standard to be called "proper"? Is it efficiency? Is it brevity? Expressiveness? Self-documentation? Maintainability? Simplicity? Uniformity? Cleverness? All of these are identifiable as positive attributes, but is any one, or some combination, a sufficient definition of beautiful code? Still further, is it possible to evaluate the aesthetic appeal of code independent of the problem it is trying to solve?

      Aside from the fact that it's nearly impossible to get two people to agree on a standard of beauty, programmers are notoriously idiosyncratic, especially in as syntactically forgiving a language as Perl. Add to this the fact that the OP wants HTML authors to appreciate the allegedly beautiful code and you have an absurdity. You can show me the most finely-crafted, moving, subtle sentence ... in Turkish ... and I couldn't distinguish it from the drunken rantings scrawled on a bathroom stall. I don't know Turkish.

      Sorry to be a wet blanket (again), but this really is a futile exercise. If the intention is to demonstrate to people unfamiliar with Perl that it is a valuable language, show them how to solve problems with it. Show them what it can do, because they simply haven't got the necessary experience to appreciate whatever notion of beauty the code itself allegedly possesses.


      "The dead do not recognize context" -- Kai, Lexx
        Well, if you ask me, it's a lot different to have

        if($var=~/hello/){$first="hello";$second="world"}

        than to have

        if ( $var =~ /hello/ ) { $first="hello"; $second="world" }

        or even

        if ( $var =~ /hello/ ) { $first = "hello"; $second = "world" }

        So no, it is not a futile exercise!

        I agree with everything you say, apart from "this is a futile exercise".

        It's not a matter of finding the most beautiful code, because we all know opinions differ. It's just a matter of finding code that is reasonably well written to be understood with... well, at least with not so many problems as with the first example I showed.

Re^2: Beautiful Perl
by cLive ;-) (Prior) on Mar 27, 2005 at 06:59 UTC

    I'd love to see your code review if you were on my team :) We have 7 guys all coding Perl at various levels of "Beauty".

    But they stick to some key rules for the sanity of the team:

    • comment often - I can scan comments a lot quicker than code to get to the bit I need to work on
    • indent 4 spaces - trivial, but helps a lot in terms of indentation expectations when reading nested stuff
    • use common code if it exists - just plain sensible
    • dereference using $var-> rather than $$var (it's just plain more readable)

    Of course, not everyone sticks to all these rules, all the time - and the times that they haven't have caused real pain (well, at least for item one on the list, especially on old code)

    Maybe you're old school - obscurity is job security. Wouldn't work here. If I can't drop into your code and scan a page in a couple of seconds and understand it, my job is harder, and your responsibilities would suddenly scale back ;-)

    Or maybe that's just me :)

    cLive ;-)

      Y'know, after turning thirty last Fall, being called Old School feels, well, kinda, oddly, amelioritive. <cheers>To being a curmudgeon</cheers>


      "The dead do not recognize context" -- Kai, Lexx