What one can learn from Perl:

When programming in a language you hate, don't take naming arguments for granted. It could be worse: you could be programming in Perl, where all arguments come in a flattened array.

This is really not much of an issue, if you bother to learn the language. If you don't, then yes, things will be confusing.

    sub named_params {
      my %P = @_; # named params in hash %P
      my $foo = $P{bar} + $P{baz};
      return $foo * $P{multiplier};
    }
    
    my $rvalue = named_params( foo => 1, bar => 2, multiplier => 3 );

Or, some people prefer to just pass in a hash reference:

    sub named_params_hashref {
      my $P = shift;
      my $foo = $P->{bar} + $P->{baz};
      return $foo * $P->{multiplier};
    }
    my $rvalue = named_params_hashref({
      foo => 1,
      bar => 2,
      multiplier => 3,
    });

But of course, why bother letting common sense, and a single line of code stand in the way of your chance to deliver a pithy remark?

just like in javascript - oh wait, that is the shiny new trend in programming, there it can't be bad thing the lack of named params.

"PySlice" with karma 25 is probably your trolling account. If not, ASK about stuff you have no clue about. It is better than looking like a little troll kid, having "fun" lowering the quality of HN by stupid language war comments.

>>where all arguments come in a flattened array

That is optional, through the power of CPAN (and kbenson's methods, of course). Examples of alternatives:

http://search.cpan.org/~barefoot/Method-Signatures-20130222/...

http://search.cpan.org/~flora/MooseX-Declare-0.35/lib/MooseX...

http://search.cpan.org/~ether/MooseX-Method-Signatures-0.44/...

(Depending on if you use Moose or not.)

One of the cool parts of Perl is that the language is extensible, that is why it e.g. has a better OO than Python, Ruby, etc. (Or simple typing of parameter arguments, see the modules above. Or why MooseX::Declare has ... ah, look yourself, troll.)

"the" language is then more of a loosely couples family of languages.

Not half as much as any Lisp variant with good macros.

Edit: The possibility to extend your environment is generally seen as a good thing, unless you believe in cleanliness of bloo... languages for ideological reasons.

That is a lie. Some of the arguments are provided as global variables like $_, (no need to remember its name, since its value will be implicitly used whenever you omit a necessary argument) whose value is decided by something akin to Clippy choosing what seems most handy.

$_ is not global, it's lexical. It's value is not haphazardly chosen, it is the topic for structures that topicalize.

You seem to be proving what I said earlier[1]. You think you understand what's going on, but in truth you don't. Feel free to continue making assertions regarding things you don't know, I can't stop you, but be aware that to do so is dishonest.

[1]: https://news.ycombinator.com/item?id=5657901

$_ is very clearly and sharply defined. Only because you never took even a slightly look at the documentation does not mean you should just make up things. :)

I don't think that is a misconception.

Perl is the language with the highest occurrence of "subtle" and "ambiguous" in its documentation and tutorials that I have ever seen. Humans may be subtle and ambiguous, but programming languages should be clear and precise.

If you contrast the original statement i quoted as a misconception, you will find that your opinion still is not the same as the actual misconception.

> bring a knife to a gun fight

> If the goal of the competition is to slice apples

What?

I disagree with the premise in a similarly nonsensical fashion. (I mentioned neither execution performance nor weapons in my reply.)

The ultimate goal in a competition is to solve the problem within a fixed amount of time. This requires you to actually implement the solution to be able to run it. If you are able to do that more easily with a language that is inferior in execution speed, that will probably be the best strategy. At least compared to using a really fast language that you are not as comfortable with.

Perl eats C++'s "most vexing parse" for breakfast.

The standard music notation and the criticism this new notation receives here look to me as if we were stuck for centuries with only one programming language, C++, and nobody could change it.

Sure, it has been working fine for many years, and a die-hard fan of C++ would come up with many criticisms of anything new: No pointers? It's for beginners only. Garbage collection? I can see the programmers that created it are not very proficient. Etc. etc. etc.

And you know what? There are really great programming languages that do many things differently and also work very well, or even better than C++. They are not perfect, but the traditional way of doing things (C++ or the standard music notation) was not perfect either to begin with.

So, I hope people experiment more and more with new notations, and maybe they will improve the standard notation or even replace it someday.

After your excelent suggestions for names (makeMapper and makeGetter, they make everything easier, thank you), I'll try answering this, with a F#-like syntax using redundant parentheses around arguments to make them more explicit to those who don't know F#

Let's suppose map is defined as:

> let map (aList) (aFunction) = ...something here...

(this is according to https://github.com/raganwald/allong.es/blob/master/README.md which seems to have the parameters reversed when compared to F#'s Seq.map, Lis.map, etc.)

And let's suppose applyLast is defined as:

> let applyLast (aFunction) (anArgument) = (fun (x) -> aFunction (x) (anArgument))

So makeMapper is:

> let makeMapper = applyLast (map)

Read the above as: makeMapper is a function just like applyLast, but the first argument (to applyLast) is already provided, being "map". The functionality of applyFirst is implicit when the remanining parameters are missing, so we only need applyLast.

So makeMapper is called as

> let mapperWithAGetter = makeMapper (aGetter)

This completes the call to applyLast, so now we have a (fun (x) -> map (x) (aGetter))

Now we only need to bind x. The result is called like this

> mapperWithAGetter (aList)

IMO, all of this could've been written as:

> let makeMapper (aGetter) = fun (aList) -> map (aList) (aGetter)

Or:

> let makeMapper (aGetter) (aList) = map (aList) (aGetter)

Read both as: makeMapper takes aGetter and returns a function which takes aList

Notice that everything would be much easiear if map took aFunction as its first parameter:

> let map (aFunction) (aList) = ...

> let makeMapper = map // duh

Remember that partial application is implicit!

It would also be easier if applyLast had better syntax, using _ for the missing parameter (the first), as in this Scala-like snippet:

> def makeMapper(aGetter: Any => Any): List[Any] => List[Any] = { _.map(aGetter) }

(I guess Haskell has some nice syntax for this too, but I don't think F# has anything like this)

All of this was not easy to get right, I hope I didn't make any mistake regarding the position and number of parameters.

Your example is great, but it would be even more convincing if it used list comprehension syntax such as

totals = [order.total for order in orders]

(like some other poster in this thread did)

Then you don't even need to know what "map" means, you only need to know "for" (well, maybe you would need an insight that "order" is defined after its use, but I digress)

Can I upvote you twice?

More than once I have found about a new technique in language A and thought: "Wow, this is clever". Then sometime later I learnt language B where that technique is not only common place, but has some nice syntax sugar and is used throughout the whole standard library. And that makes a huge difference in the perceived cleverness of the code.

I went in the other direction and it was enlightening too. I learned how useful hash tables can be, and that a word count algorithm need not be a complicated assignment full of segmentation faults. :-)

I also learned how data structure libraries can be separated from user code (when learning C in class we usually created ad-hoc data structures heavily coupled with the calling code).

I remember some years ago when I was glad Java 5 had got some really practical new features. I didn't program in Java back then, but I wanted the language to evolve (maybe I was going to need it in the future).

Now I do program in Java 5/6 and it would be really sad if the language was still stuck in the 1.4 days.