All programming languages suck.

[tyggerjai]

This post is brought to you by recent excursions in The Lacuna Expanse. You can probably skip this post and go straight there, unless you're a perl weenie. If you *are* a perl weenie, you may enjoy TLE. Not only is their API published and well documented, they encourage scripting and bot writing. You could, legitimately, write a bot to run your entire empire, and never log in again, and they'd be cool with that.


Anyway.
I have never been a fan of perl's map function.

There. I've said it. It confuses me, and makes me feel stupid. Partly, of course, this is self-fulfilling - I don't like it, so I don't use it, so I don't understand it when I see it, so I fear it, so I don't like it ....

Working in Lisp a bit recently has, oddly, increased both my understanding *and* my dislike. So I'd like to be educated.

Dear perl hackers. Does map give me *anything* other than syntactic sugar, or perhaps the opposite?

Part of this stems from recently getting up to speed with Python, which has Only One Way To Do It, which means, when you see It, you know exactly what It Is Doing. I've been reading a lot of other people's perl lately, some of it quite old and crufty, and I'm struck by the tendency of perl hackers to be clever. And that's nice, and all, but sometimes it's not. And oh, I know, the community is diverse and all, but it does my head in to go to "help" communities that emphasise clear and readable code, and then say "And you know that annoying 4 line foreach loop? You can replace it with a single line of incomprehensible punctuation using map, in case carriage return is expensive on your machine!".

Which said, I may be missing something. Should I be using map, and if so, why? What does it give me other than shorter code? Do you find it just as easy to parse as a nice foreach loop, or can you do things with it that you just couldn't do with foreach?

On a related note, I think this has something to do with my innate distrust of "$_". I know, I know, "$_" is a defining characteristic of the language, but still. It's *clever*, and I don't always like clever. So map not only generally has $_ scattered throughout, but by definition, when reading it, you get to $_ before you have *any* idea what actual set the map is working on.

This, I suppose, is why I no longer code for a living, but I wonder how much of it really does just have to do with perl.

Comments

[tyggerjai]

Yeah. Not sure I like that either :)

I think it's a personal thing. If it's a test, and then a func to do to things, then they're logically separate. So separate them. A large part of it may be confidence, too - if I have

for thing in stuff
do stuff to thing

then when it all goes horribly wrong, I can add "print thing" before the do stuff.
Or it occurs to me that I need to clean the stuff before I do the thing, so I can put "clean stuff" before "do thing".

And with a loop, I can just add lines. With any sort of one liner, I look at it and think "Um....". And kariela is right, I can just keep adding pipes, but that very quickly becomes a whole line of noise, and if I have to add one thing, I'll probably have to add other things. And then I have to print the things I got from the first stuff before I do the second stuff and oh god I hate it.

So I think it's actually language independent. If you're doing things to stuff, get the stuff, then do things to it, don't try to do it all at once!

And bringing it back to Lisp, from the little I know, you *do* break it up over lines, and you can just make it (otherstuff (stuff (things))) *or* (stuff (otherstuff(things))) at any point in there. But it probably sucks in lisp too.

[jeamland]

That's kinda the point I was getting at in terms of it getting ugly really fast if you try to do too much. If, however, you're trying to do a quick transform on a list it's nice and expressive. The kinds of things I use it for are:

strings = [str(x) for x in maybe_strings]
less_than_5 = [x for x in numbers if x < 5]
numbers_if_not_none = [int(x) for x in things if x is not None]

and the like. Anything that's more complicated than that generally gets done in a for loop.

[tyggerjai]

Yeah. The example Kariela gave that made me think "Oh, that's actually handy" was:

my @newlist = map { "text-prefix" . $_ } qw(some array of plan text right there);

or, see if I get this right

newlist = [ ("text-prefix" + x) for x in ["some", "array", "of", "plain" "text"]]

So I can see the text, I can see it's only adding a text string, it's the Right Solution (tm). Because you are, literally, mapping a string to a new string. Not some poorly defined possible result of a method that may or may not return something to some other whacky transformation.

So it's not perl's fault. Poor misunderstood perl.

[thorfinn]

It's always the programmer's fault. ;-)

[sophie]

Yeah, you can do that sort of thing in Perl too, it's just not as pretty. For example, your second example would be this one-liner in Perl:

@less_than_5 = grep { $_ < 5 } @numbers;

The third example is more difficult if you *really* want a one-liner, since you're modifying the array as well:

@numbers_if_not_none = map { int($_) } grep { defined($_) } @things;

I wouldn't write that second one as a one-liner, myself. I would do:

my @numbers_if_not_none = ();
foreach my $number (@things) {
  if (defined($number)) { push(@numbers_if_not_none, int($number)); }
}

Some other people might write the line in the loop as:

push(@numbers_if_not_none, int($number)) if defined($number);

...but I personally prefer putting the if first.