I've never thought maintenance programmers should be the least experienced ones. It's not so much experience but temperment that divides people into which phase they work in, I think, although no one seems to think about that when making the assignments.

I've been at a few places that get nervous when they look at my code and see a lot of map statements. I don't tend to write dense code, so it's not that they can't pick out the flow. They just don't map yet. However, I'm not going to give it up. For the money I get paid, they should use all my skills. Otherwise they could hire at the same price three guys who don't know map.

There are things that I just don't use for client work: source filters, Spiffy, typeglob magic, odd B hacking, and so on. That stuff is a little much to ask of the typical Perl programmer who's just doing his day job (instead of someone like me who writes about Perl, publishes a magazine about it, and works with Randal).

In all of this, people need to develop good reading habits in themselves and the people they have to work around. Some places I've worked even have a "team library" with all the right books (with several copies in some places). If you run into something you don't know, pull out the Camel book and learn about it. Write a couple of dinky scripts to play with that feature without worrying about making it work in a big program that has sorts of other (broken) things going on. Don't get turned off because it seems weird at first. Everything seems weird at first.

Along with that, we encourage people to develop a style guide, and talk about hwo they are going to code. This can include the features they are not going to use along with a justification for it (since they'll have to explain it to every new person anyway). Often, there isn't any good reason other than FUD, and the exercise of writing it out usually makes them realize that.

In the end, if we are going to code to the lowest common demoninator, we can get rid of strict, lexicals, and subroutines. :)

In the end, if we are going to code to the lowest common demoninator, we can get rid of strict, lexicals, and subroutines. :)

i think this is what i was getting at. while i won't pretend to say my skills hold a candle to yours, i can tell by looking at the old codebase at this company that i'm the most experienced person that's been there ... i know i need to do more to document things, but i'm always stuck in the trenches.

i do tend to write a ton of little toy scripts to make sure function X does what i thought it did ( my homedir is full of them ), and refer back to them when needed.

i want to leave behind a way that people can learn something as well as have tight code that works properly.

just to clarify -- i don't think mainentance programmers have to be of a 'lesser' skill set than the original developer. i'm also a big fan of the Kernigan quote mentioned in another reply, and it has proven true at this job, because i've fixed longstanding bugs that the original (no longer at the company) developer just couldn't fix.

overcoming the managerial resistance is the biggest issue at this place. i've had a hell of a time convincing him that we need things like *shared* libraries, better source control, etc. because he's more concerned with ease of tossing a client their code if they leave than with making the developers' jobs simpler and easier.

Therefore if you find that you're having trouble using all of the features that you want to use, that is a sign of real trouble lurking ahead. If you're having trouble just figuring out how to make the code work, then you're going to have little left over to spend on considering how to make your intentions obvious to the maintainance programmer, or considering whether the feature makes sense in this place.

As I pointed out in The path to mastery, I consider it more important to learn how to use features well than it is to pack as many features as possible into code.

That said, advanced features have a definite place. But they come with a cost. Part of the cost you've already mentioned, you require more skill from your maintainance programmer. You can get better productivity for that effort though.

Personally I think that it is valuable to clearly define what skills you think a maintainance programmer should have. Then stick within that skillset, and also actively verify that others in your environment have those skills, and agree with you that those skills are not too much (or too little!) to ask for. I've done this in the past with some success. It is not that some features were "too advanced" to use. It was that I decided what mix of advanced features I'd make sure that people could support, and then I'd stick within that set.

... the decision you make depends on what is important to you. You have to ask yourself who the code is really going to be read by.

Seconded. Consider the future lifecycle of your software/project/company... Are they likely to end up hiring inexperienced developers to work on this in the future, or is this an avenue they need to keep open?

If that doesn't seem particularly likely, I'd suggest using the "advanced" features -- they'll make your code more succinct, which is a benefit in and of itself.

while i do agree with the sentiment (one of the reasons i'm asking for added wisdom), if a new guy comes along ... isn't reading and maintaining the code of someone "more senior" that actually works a good way to gain experience?

i totally admit that if i were doing esoteric tricks a la, say, thedamian ... i'd be worried. but we're talking about map here, not strange perl-OO bag-o-tricks that make your brain throb.

i was trying to get a combination of map and grep working to set a selected element to pass to HTML::Template without using a foreach loop.

Um, why? What's wrong with foreach loops?

In my opinion, code like this:

my $parts = [ 'Part1', 'Part2','Part3' ];

my $newLoop = [ grep { $_->{SELECTED}++ 
                  if $_->{PARTNAME} eq $row->{title}, $_ }
                map +{ 'PARTNAME' => $_ }, @$parts ] ;
[download]

is bad even if it works, which--as you found out--it doesn't. grep/map are great as list filters, when you want to build one list from another, but they force you to stuff all of your code in one tiny block/expression. foreach is the general-purpose list iterator, and you should always be ready to fallback on it if grep or map get too hairy, like revdiablo showed you:

for (@$parts) {
  my $hash = { PARTNAME => $_ };

  $hash->{SELECTED}++
      if $_ eq $row->{title};

  push @$newLoop, $hash;
}
[download]

foreach is your friend.

UPDATE: -2? What was so objectionable about suggesting Perl programmers use a clearer construct over a shorter one?

grep/map are great as list filters, when you want to build one list from another, but they force you to stuff all of your code in one tiny block/expression.

Well, this problem is to build one list from another. Your example builds one list from another. To be clear though: grep is a filter, but map is a transformer.

Neither map nor grep force you to do stuff anything anywhere. There is no magic rule that says it has to fit on one line. You're doing all that work in the foreach anyway (although you're stuffing much more stuff into it).

Consider what is important in the problem. Is it iterating through each element and doing something, or is it creating a new list? In this case, it sure looks like the new list is the point of the exercise, so it should get top billing. When you use map, you emphasize the new list. When you use foreach, you bury the list creation in a bunch of other code. The new list doesn't stand out. Using foreach in this instance may make the syntax readable to anyone with a week's worth of Perl under their belt, but it doesn't make the program logic more readable.

@$newLoop = map {
  my $hash = { PARTNAME => $_ };

  $hash->{SELECTED}++
      if $_ eq $row->{title};

  $hash;
  } @$parts;
[download]

--
brian d foy <bdfoy@cpan.org>

I disagree. For complex expressions, foreach can always be made more readable than map, because foreach lets you explicitly name the variable that stores each element from the list you're iterating over. Again, this is why I prefer it for anything more than single-statement greps or maps. It may take a little more typing, but in the end, it's clearer and more readable, and yeah, I guess a little easier on the novices too...

Um, why? What's wrong with foreach loops?

Nothing, but the way you state this suggests there's something wrong with map and/or grep. Why is that?

IMO, foreach and map/grep are equivalent. Neither is inherently more clear than the other - people finding one construct more clear than the other usually base this preference (knowingly or not) on their experience with other languages. Many Perl programmers have learned programming in a language that has for/foreach like loops, but don't have map like constructs (C and Java for instance) - and many, if not all, Perl books and tutorials teach for/foreach long before they introduce map, and spend a lot more time explaining for/foreach than map or grep. People who are familiar with Lisp, Scheme, or other functional programming languages consider map/grep less exotic.

grep/map are great as list filters, when you want to build one list from another, but they force you to stuff all of your code in one tiny block/expression. foreach is the general-purpose list iterator, and you should always be ready to fallback on it if grep or map get too hairy

Either you don't understand map/grep, you don't understand for/foreach, or you don't understand either. A foreach construct looks like:

    foreach (LIST) {BLOCK}    # or
    foreach ITERATOR (LIST) {BLOCK}
[download]

while a map construct looks like:

    map {BLOCK} LIST;         # or
    map EXPRESSION, LIST;
[download]

So, either construct requires a keyword, a block and a list. The difference is that with one construct you place the list before the block (and need some addition keystrokes), and the block last. The other construct places the list at the end, with the block proceeding the list. In many cases, the blocks used can be identical - the block used by map can be as large as the one used by foreach (or should I say that foreach forces you to stuff all your code in a tiny block?).

What was so objectionable about suggesting Perl programmers use a clearer construct over a shorter one?

Nothing at all. What is objectionable is to suggest that you can objectively say that foreach is clearer than map. Stating that foreach is clearer than map just shows your inexperience in programming techniques.

Nothing, but the way you state this suggests there's something wrong with map and/or grep. Why is that?

I never said that there was something wrong with grep or map, I said that the original poster's usage of grep and map combined--which didn't even work--was bad, and that in general I preferred foreach over greps and maps with multi-statement blocks.

Neither is inherently more clear than the other - people finding one construct more clear than the other usually base this preference (knowingly or not) on their experience with other languages.

I base my preference on the knowledge that variable names are perhaps the single most powerful form of documentation programmers have available to them, and one construct encourages you to give a name to list iterator while the other doesn't. Furthermore, map blocks are indeed meant to be short because each one is evaluated for its result. Thus, if you have a single statement map block like this:

my @content = map {$_->content} @responses;
[download]

It all works out nicely, but if you want to do anything more complicated, you end up combining multiple statements into one, like so:

my @content = map { escape_html(convert_newlines($_->content)) } @resp
+onses;
[download]

Or as Brian showed, separating them and then tacking on the result at the very end to make sure the block gets evaluated properly:

my @content = map {
    my $content = $_->content;

    convert_newlines($content);
    escape_html($content);

    $content;
} @responses;
[download]

And not only that, in my personal aesthetic opinion, grep/map combined with $_ are just plain uglier than foreach is, especially when you need to toss in a "+" or two to help the parser, as the OP did.

What is objectionable is to suggest that you can objectively say that foreach is clearer than map.

Did you actually bother to check the original node? Here, you compare one with the other and you decide which you think is more readable:

my $parts = [ 'Part1', 'Part2','Part3' ];
my $newLoop;

for (@$parts) {
  my $hash = { PARTNAME => $_ };

  $hash->{SELECTED}++
      if $_ eq $row->{title};

  push @$newLoop, $hash;
}

# ----

my $parts = [ 'Part1', 'Part2','Part3' ];
my $newLoop = [ map {{ PARTNAME => $_,
                        $_ eq $row->{title}
                           ? (SELECTED => 1)
                           : ()
                    }} @$parts ];
[download]

Stating that foreach is clearer than map just shows your inexperience in programming techniques.

Well, I've posted lots of code here before, so I'm more than willing to let my technique speak for itself. I'll admit that I often use grep and map freely with no inhabitions at all, but not in code that ever sees the light of day. I would be less than thrilled if I was presented with a large codebase to work on full of constructs like the OP's.

I'd only note that using foreach/push instead of a single assignment requires more work on the part of the interpreter. It'd be a trade-off on whether I valued the work savings on the part of the interpreter over the ability of novices to read the code.

Right, but "$string =~ /$substring/" requires more work on the part of the interpreter than plain "index($string, $substring)" does, yet only a minority of Perl hackers bother to touch index/rindex at all.

If you're going to go to all the trouble of programming in Perl, then program in Perl! Don't program in Perl-Lite! What's the fun in that??

Tilly and brian d'foy best stated the theory for balance between feature and maintenance. But to add some more concrete decision points to blahblahblah's comments, consider this:

Advanced features of a language really best serve one of three purposes, and usually only one at a time.

1. performance increase
2. readability increase
3. obfuscated code entry

In the first case, it goes without saying the performance increase needs to be noticable, not just measurable to be worth the effort of cluttering the code with complexity, let alone the effort of even working out the code in the first place. Then, it should be heavily documented including what the "simpler" code would have looked like in the comments.

In the second case, advanced features can actually make code EASIER to read if done right. Unfortunatly your sample is hardly that. reference = grep, if and map is hardly adding any clarity to the issue. If done right, advanced coding features and techniques can actually **HIDE** code complexity from all except those who really need it. In other words, make the code readable as in a "Coding by Intention" sort of way and leave the complex parts hidden in subroutines that only need to get looked at if you are debugging that actual segment. This leaves the mainline of code more clear. After all, loops come with a certain amount of clutter also (counters, test conditions, etc).

The third case is of course irrelavent to the discussion of production code :-)

Production code is not the place to educate the masses. Neither is it a place for needless obscurity. While many of your points I believe are valid, this particular code sample does not qualify. I think your philosophy is valid if tempered with the rules above and those mentioned by blah-cubed.

neniro

1. You consider yourself one of the most advanced perl programmers at your company.
2. You needed to post a question to perlmonks to figure out how to write the code.

What I usually do when I've written something that took me a while to figure out, or that I think might take someone else a while to figure out, is to comment my intentions. That serves at least 2 purposes well: 1) someone skimming the code can look at this section and quickly understand what it's supposed to do, without having to understand the code. 2) if someone needs to debug my code, they at least know what I intended, and can be sure that I wasn't relying on some side-effect, or counting on some behavior for some special case.

Also, if I got help understanding it from some online source or some book, I'll include a link or a book name & page number in the comment to help others.

i guess the points needs clarification:

1. You consider yourself one of the most advanced perl programmers at your company.
at the moment, i'm actually the *only* programmer at the company, perl or otherwise. (i admit i still have a bias that says HTML via Dreamweaver isn't programming). it's a small company ... 3 people.

2. You needed to post a question to perlmonks to figure out how to write the code.
i'll give you that one, but the only way i can get another pair of eyes on *anything* at this point is to post. more of a logistics problem than anything else. plus, by posting, i got a better solution than what i was banging my head on ....

although, if i'm banging my head on it, chances are others would too ... but i do hope people can learn from my (publically viewable) mistakes ....

Howdy!

...well, HTML is coding, but it ain't programming...so I ratify your bias

yours,
Michael