Wrong parameter ordering for `List.map` and similar functions

[rkrisztian]

You have probably heard of the Yoda code style, or Yoda conditionals (blue is the sky, usually expressed as "blue" == sky). We don't like such style because they break the reader's natural flow or reading: they put the blue in focus, rather than the sky, which is the main subject of the comparison). What does that have anything to do with code like the following?

List.map((n) => n + 3, [1, 2, 3])

Two things:

1. When I read this statement, I read it as map to n+3 the list [1, 2, 3]. Rather than something like, map [1, 2, 3] to n+3.
2. When the last parameter is the function expression, the function part can be naturally broken down into multiple lines. Consider the following bad design from JavaScript:

   setTimeout(() => {
       alert("Hello");
   }, 3000);

   Arguably it can be read as Do an alert 3 seconds later, but it sounds closer to the original code if I say set for this function a 3-second timeout, rather than set a 3-second timeout for this function.
   In Groovy we know that if the closure is the last parameter, then we can write it in a more readable style (this is hypothetical code):

   setTimeout(3000) {
       alert 'Hello'
   }

   Also consider Gradle task declarations. They would likely irritate the reader if they were created like this:

   task({
        // configure this task...
   }, 'myTask')

So please reconsider the ordering of parameters. Make them more natural to readers. Sadly several languages don't get it right. And I didn't even mention that [1, 2, 3].map((n) => n + 3) would look even more natural to read. The static method call way is verbose. The best languages combine OOP and FP styles together. See Kotlin for example.

[rkrisztian]

Sorry, this issue was opened in the wrong repo. => Recreated as grain-lang/grain#671