Re: mini-quiz

On Tue, 19 Jun 2007 12:50am, Ron Isaacson wrote:
> Joshua Kronengold wrote:
>>  >>  my $country = map +(/^(?:|gbr)$/ ? '' : uc),$card->country;
>>
>>  [...] is much better.

> Sorry, but you lost me there. I consider myself to be a pretty darn
> good perl programmer, and even I'd have to read that line a few times
> to understand its meaning.

*blink*  really?  which part and why?  Is some of this idiomatic 
unfamiliarity? Would this help?

my $country = map +(/^(?:|gbr)$/ ? '' : uc "[$_]") =>
                        $card->country;

How about:
my %ignored = map +($_ => undef) => ('', qw(gbr)):

my $country = map +(exists $ignored{$_}
                           ? ''
                           : uc "[$_]") => $card->country;

>   if ($country eq 'gbr') {
>     $country = '';
>   } elsif ($country ne '') {
>     $country = uc "[$country]";
>   }
>
> I'm sure someone will find a way to clarify it even more, but to me,
> that's a one-pass read and the meaning smacks you over the head.

Yes.  But the same is true of my code, ignoring idiomatic unfamilarity.

> You're honestly telling me this block would be HARDER for an expert
> programmer to maintain (i.e., tweak if the desired logic changes
> slightly) than your one-line version above?

No, on its own.  Yes, in that a subroutine written in that style could 
easily become a 500+  (or even 50+) line mess that was as a whole far 
less comprehensible and maintainable than the same thing writ shorter.

All too often, I've encountered code like this:

my $str = "initial";

if(test) {
    $str .= thing
} else {
    $str .= otherthing
}


if(test2) {
    $str .= thing2
} else {
    $str .= otherthing2
}

Which quickly became nigh-unmaintainable and incomprehensible (what was 
worse was that it was actually using reverse concatnations, ie 
"$str=thing.$str".  which was largely invisible due to the length).

The same thing would have been entirely readalbe and comprehensible at a 
glance were it instead writ as:

my $str = join '' =>
  ( init,
    (test1 ? thing : otherthing),
    (test2 ? thing2 : otherthing),
  );

> entirely, and an expert
> understanding of the nuances of the perl language by all of our
> developers wouldn't necessarily help us accomplish that mission.

There -is- a question of how much work it takes to get an idiomatic 
understanding of perl.  Having coded perl for 10 years at a variety of 
levels of understanding, I'd say the biggest factor is environment.  If 
you already have a number of programers with a strong understanding of 
idiomatic perl, it doesn't take much effort to train new programmers to 
a similar level of comprehension -- the constructs themselves aren't 
difficult.

On the other hand, if your leads are still unfamilair with, say, hash 
slicing and closures, it becomes increasingly harder to get to this 
level, and may not even be worthwhile.

> I suppose the most important thing for any technology (including a
> programming language) is to apply it in a way that's appropriate for
> the problem it's intended to solve and the environment in which it
> will be used.

Yes -- agreed.