Front page | perl.perl5.porters |
Postings from May 2000
Re: Thoughts on maintaining perl
From:
Ben_Tilly
Date:
May 25, 2000 14:04
Subject:
Re: Thoughts on maintaining perl
Message ID:
OF8B960D12.FBD9CA74-ON852568EA.0073AEBB@trepp.com
David Adler wrote:
> On Thu, May 25, 2000 at 03:27:51PM -0400, Ben_Tilly@trepp.com wrote:
>
> > print join ",", map { &{$field_info{$_}{format}}($deal) } @fields;
> >
> > It took me some time to figure out what that construct meant[...]
> >
> > That turned out to be a good lesson for me. This construct really was
> > integral to his style, and once I got past the shock of that line it
> > really was maintainable.
>
> The question that springs to my mind is "was there a comment
> explaining this?" If not, would that have prevented it from "stopping
> you in your tracks"? Also, if not, hurt that man. :-)
No, and no.
What comment would you put to explain it that would really help
someone who has not seen it? What comment does someone need who
knows it is coming? It is part of a philosophy of programming. He
got it from Lisp. I seen him demonstrate variations on it in Perl,
C, C++, and JavaScript. In fact the first question he has about a
language is, "Does it support closures?"
As you can see, this construct or something like it appears in a
significant portion of his programs in any language at a critical
place. After you first face it, you know what it does and it
always does the same thing. The fact that it will be there is
obvious through the entire program. You have configuration. And you
have logic. Then you combine them in some magic call. Once the
logic is right, the configuration is straightforward to maintain.
Once again I think this is fine if you do it all of the time and the
people around you are prepared for it. It is a very nasty trick to
pull on people who are not ready for it. I only brought it up
because it fit the bill of what Chris asked for.
> It seems to me that if you have code that might look a bit obscure,
> but can be comprehended with little trouble if you know what it's
> *supposed* to do, then you *tell* people what it's supposed to do.
Oh trust me, it is a very indirect style. My experience was that
being told about it was useless. It is a very indirect way of
thinking, and until you catch on to that indirection you *will* be
confused at what is going on. Even in the simple bits. :-)
> Again, not an issue with the language, but with the programmer.
Oh *THAT* is definitely true. :-)
Again, I do not recommend this as a general technique.
> *sprinkles IMHOs around to cover his tracks* :-)
:-) :-)
Cheers,
Ben