Sorting an array based on sort order of another array

Let's say you have an array of names and a corresponding array of salaries, i.e. the first name earns the first salary, etc. The salaries can have multiple identical entries. Now I want to know who earns the most, the second most, etc. I can sort the salaries:

Code:

@salaries = sort { $a <=> $b } @salaries;

Is there a simple way that I can then ask that the names array sort itself in the same order that the salaries array sorted itself?

map is going to apply some function across each item in an array. The array is the same as @sorted_persons above. The function is put in curly brackets, and it's just to take each key for %wages and stick that into $_ and then create (?) the appropriate phrase. Or something like that? And then print prints out the whole thing? Sorry for my ignorance here, but I'm a bit confused and any guidance would be appreciated.

It's not completely obfuscated, but it's doing a lot in a single line, that's for sure.

Map is a function that works on an array. Actually, all the functions in that line work with lists, or arrays. Print prints a list of strings. You generally only see a single item, but it works with lists, so you can print an array with one line for example.

Map works with a list. Here it is building an array of strings for the print function. Sort works on an array obviously, and 'keys' is a function that returns a list.

each element of the @sorted array is aliased to $_ and the map functions creates a string made of the array element ($_), a colon and a space, the hash value corresponding to $_, and a new line character, and return that string into the @string array.

I do not think that my code above was obfuscated. I can understand that it is not obvious for someone not used for this type of LISP-like chaining up of list functions, but the construct is actually very natural, somewhat similar with successions of pipes under Unix, in fact simpler that the "decorate-sort-undecorate" concept of the Schwaztian transform".

Also, I gave that code only as a second option, as a slightly more fancy alternative to a simpler and typical pure sort example.

Using three split's, four map's, one sort and one join in the same instruction is a performance that leaves the Schwartzian transform far behind. ;-)

And the aim was not to illustrate the power of such constructs with a crazy example made for that purpose, this code actually solved a real question really asked by someone on this forum.

But, then, to tell the truth, I certainly did not recommend such a construct (here, I think I would accept the word obfuscated, even though obfuscation was certainly not the intent).

It was just a somewhat extreme example that I gave (on the second page of this post: http://forums.devshed.com/perl-programming-6/data-parsing-was-need-help-in-perl-943498.html?pp=15), after explaining a similar construct made in two successive instructions instead of just one. As I explained on that post, I originally really needed to do it in two parts to check that the constructed data structure was what I wanted.

My apologies. I did say "It's not completely obfuscated", when I did mean "It's not obfuscated."

But it is a busy line. By breaking it out, I hope it will be clearer to the poster, or perhaps he can single out one line as the source of his confusion.

Don't worry Keath, I did not feel offended and you don't need to apologize.

When I said that I did not think it was obfuscated, I only meant to say that using chained list operators is a very powerful feature of Perl (not only Perl, BTW, but Perl does is quite neatly), and that I do think that when the chaining-up is very linear (one list is just fed to the next operator, and so on) as in my suggested solution, it is in my view actually quite easy to understand with a minimal amount of explanation.

I think it is a very useful and powerful feature of Perl lists operators, and that it can be used more broadly without falling into the trap of obfuscation.

The other example I gave, the new one in my earlier reply, is definitely starting to get quite obfuscated, I agree, although it is written as cleanly as possible and without trying to obfuscate at all, it is just getting slightly too complicated. But, as I said before, this was just an example of how far the paradigm could be pushed, even on a real life example. I would not use such a hairy construct in real life, and my original solution was spliting it into two parts, one to create the data structure in memory (and check under the debugger that it was correct), and a second one to output the result.

I, the original poster, am really grateful for this discussion. Not only did it answer my original question, but I learned a lot of other stuff. For example, I wasn't even aware of the concept of perl lists. Googling that taught me something. Anyway, thanks all for the responses and discussion. It really helped me.