I guess I could shorten the previous posting.
Please don’t sell Elixir as an FPL - it’s not it’s a CPL (Concurrent Programming Language)
Don’t get into “my FPL is purer than yours” arguments. Don’t even think about talking about Monads. Change the subject.
“What’s a CPL?”
“You know, the kind of stuff the WhatsApp servers are written in …”
There used to be via ‘Tuple Call’, but that feature was removed from the BEAM at the behest of Elixir in the most recent version, now it can only be used if a compiler option is passed in.
I was looking for this! But yes, OCaml does not have automatic currying at definition site. In OCaml a proper inlineable efficient function definition and usage would be:
let add(a, b) = a + b
let 3 = add(1, 2)
Conceptually this is a single-argument function that takes a tuple, but the OCaml compiler actually fully sets that up as a tuple-less stack-based function invocation like you would do in C++. The ‘normal’ function definition in OCaml would be:
(* short form *)
let add a b = a + b
(* long form *)
let add = fun a -> fun b -> a + b
let 3 = add 1 2
Conceptually this is a function that takes an integer and returns a function that takes an integer that returns an integer. However OCaml’s compiler is built for the very purpose of optimizing this case back into the prior one (which is why it is so blazing fast), but will create thunks as necessary for any partial application.
The ‘tuple’ form is not partial appliable though, hence why most don’t use it. In SML (OCaml’s predecessor) it does not optimize the ‘curry-style’ to normal calls very well, so it is common to see people use the tuple style as it is just faster in comparison, that is why OCaml went the other way and pretend that currying is not currying and instead makes normal functions that it partially applies via thunks on demand.
And thus yes, ‘currying is a mere frill’ is entirely true.
In my MLElixir little sandbox thing I had that same ‘currying’ style as OCaml, they are normal calls but they pretend they are not via automatic thunk generation as necessary (although the syntax I find even nicer than OCaml’s as you can partially apply any of the arguments, not just the start or end arguments ^.^).
As a long time FP’er, ‘horrible’ in this context means that you cannot pipe into a partial application, but since Elixir doesn’t have partial application it’s not as big of an issue (and thus elixir arbitrarily chose to pipe into the start argument, which I do find a touch odd honestly as erlang prefers topic-last arguments like most functional languages, but eh, it works).
It’s an aspect of the BEAM. It could have been worked around by Elixir pretty trivially via tuple calls, but I ‘think’ those are slightly slower to call than the anonymous function syntax, I’m not certain though, need benchmarking…
I find with to be more of an ‘early-out’ construct than anything moand’y, but that does handle many use-cases regardless.
And lfe for another big beam language! ^.^
But yes, the BEAM is far more proper OOP than any more traditional OOP language.
Lol, I’m swiping this. ^.^
Hey again!
First of all, I would like to thank everyone for their time and support in this discussion. The community’s response has been truly overwhelming and surprisingly positive considering the tone of my first post, which I wrote in a moment of frustration and anguish.
Since I have joined the community I have learned the true purpose of Elixir / Erlang and I have read a lot about its strengths. I am now invested in learning more and I can’t wait to bring all this knowledge to my company. I want you all to know that it was the effort the community poured into this topic that enlightened me.
Now I hope I can one day pay back, but so far I still have a long road ahead of me and that’s fine - at least now I know it.
As this discussion grows, so does the time I need to invest into reading every single post. A great number of individuals have poured their brilliant responses here and I have read them all, but it is my belief that I learned my lesson.
Now I have a plethora of other lessons I still need to learn and little time to invest in each. It is for this reason that I will stop answering comments in this discussion. It is my belief that I already got everything I could from here, and I want to invest my time learning other lessons that Elixir /Erlang both have to offer me.
If you are reading this late, or arrive here after this post, don’t feel angry nor discouraged because the original poster didn’t reply to you. I am just 1 person and you are lot. Instead if you feel that something still needs to be said do it for any future readers who may find this discussion interesting.
Thank you all!
Not sure why this decision has been made, but I can tell you it’s one of my favourite Elixir properties, because I’ve always found the ordering in Erlang stdlib confusing. Let me explain this with a simple example using :lists.map. Here’s how we map a list:
:lists.map(
fn el -> do_something(el) end,
fetch_elements_from_somewhere(...)
)
I’ve always had problems reading such code, because the order of arguments is unnatural to me. The first argument explains how each element is transformed. My problem here is that at this point I don’t know what each element is, so the information is partial. Perhaps it’s just how my mind is wired, but I usually want to know what is being transformed before knowing how is it being transformed. Thus, the reading order for me is: line 1, line 3, line 2.
I used the same order when writing code. I’d start with this:
:lists.map(
,
)
Then, I’d proceed with:
:lists.map(
,
fetch_elements_from_somewhere(...)
)
And only then would I add the mapper function.
The story is even more complicated with :lists.foldl, where reading/writing order for me is 1, 4, 3, 2
Again, perhaps it’s just how my mind works, but I find Elixir’s convention more natural, because it helps me read/write code in a more linear fashion.
It may be related to the Elixir idiom of passing optional args as an optional keyword list to functions which also supports the syntactic sugar of omitting the [.
defmodule Foo
def bar(list, opts \\ []) do
# ...
end
end
Which allows it to be used as either:
Foo.bar(list)Foo.bar(list, [an: arg])Foo.bar(list, an: arg)list |> Foo.bar([an: arg]) |> ...
Good point, I think that requires the piped-in arg to be first.
I just want to say that for someone who is not used to other languages that have something like this, Elixir’s way is far more intuitive. The piped-in arg is on the left of the call it’s being piped into, so why on earth should it become the rightmost argument of the call??? It’s coming in from the left, it should go into the left “slot” 
Well… Just turn the pipe operator around the other way and set up the language so function execution proceeds from bottom to top:
last_operation() <|
middle_operation() <|
first_operation() <|
starting_data
(P.S. Don’t actually do this)