Question re default arguments in multiple matching functions

That names is your argument that gets passed on as a first argument to the next operation.
Elixir is all about transformation and we use those pipelines |> for better readability and it’s an elixir idiom.

So those lines (4 to 6) could be rewritten as:
hello(country, (Enum.join(names, ", ")))

Thank you. That makes sense to me. I have only been studying Elixir for less than 2 weeks so I have a ways to go. Again, thanks.

6 months into Elixir and I find it very hard to go back to Ruby, without its pipeline operator.

I found Dave Thomas’ book particularly stressed the pjpeline and how it forms your thinking very well. That is, the syntax isn’t mere sugar, it changes the way you think about transformations of data.

M

I wonder how hard would it be to port the pipeline operator to Ruby.

There are at least least two approaches:

This one uses the pipe | operator.
And Chainable Methods which creates a proxy object that emulates the pipe.

To be quite honest, both approaches feel too hackish, and I wouldn’t recommend anyone to use them on anything more important than a PoC. I do see a lot of value in adding the pipe operator to a future version of the language, though.

Since a Prof of mine explained the difference between OOP and imperative programming briefly as “the difference is the position of the first parameter”.

Having this in mind, one can think of the . as an alternative of elixirs pipe.

Also paradigms in OOP aren’t about transforming immutable data, but transforming mutable objects, so piping as in elixir might (semantically) not even make sense.

Last but not least, the methods you are calling needs to support chaining into another, but thats the case in elixir anyway. If a method only transforms self and returns Nil you can’t chain it. If a function in elixir just sends a message to modify thats process state and returns a simple :ok you can’t pipe that any further in a meaningful way.

@msimcoe - the pipe operator certainly allows for a really nice, straightforward way to model simple chains of function calls, but it’s good to be aware that there are better options if your needs are more complex

Strictly speaking, using pipes, you could of course handle things like a simple :ok results etc (that @NobbZ mentioned above) by crafting your functions to handle the outputs from earlier in the pipeline:

defmodule Monitor do
  def poll() do
    # Let's simulate getting some metric from a device..
    x = :rand.uniform(15)
    if x <= 12 do
      {:ok, x}
    else
      {:error, :device_failure}
    end
  end

  def check({:ok, x}) when is_integer(x) and x < 10, do: {:ok, x}
  def check({:ok, x}) when is_integer(x) and x >= 10, do: {:warning, x}
  def check({:error, _reason} = error), do: error

  def output({:ok, x}), do: IO.puts("All is ok: #{x}")
  def output({:warning, x}), do: IO.puts("WARNING: Check your x, it's getting a bit high: #{x}")
  def output({:error, reason}), do: IO.puts("ERROR: #{reason}")

  def report() do
    poll() |> check() |> output()
  end
end

iex(3)> Monitor.report()
WARNING: Check your x, it's getting a bit high: 11
:ok
iex(4)> Monitor.report()
All is ok: 9
:ok
iex(5)> Monitor.report()
ERROR: device_failure
:ok

The above functions, however, are highly coupled to each other, and most likely not useful outside their context, even if they happen to do something that you could otherwise have use for. You might be better served by using with in a more complex chain like this:

defmodule Monitor do
  def poll() do
    # Let's simulate getting some metric from a device..
    x = :rand.uniform(15)
    if x <= 12 do
      {:ok, x}
    else
      {:error, :device_failure}
    end
  end

  def check(x) when is_integer(x) and x < 10, do: {:ok, x}
  def check(x) when is_integer(x) and x >= 10, do: {:warning, x}

  def report() do
    with {:ok, x} <- poll(),
         {:ok, x} <- check(x) do
      IO.puts("All is ok: #{x}")
    else
      {:warning, x} -> IO.puts("WARNING: Check your x, it's getting a bit high: #{x}")
      {:error, reason} -> IO.puts("ERROR: #{reason}")
    end
  end
end

Now each function has only its own purpose to worry about, and report ties it all together, handling the different responses that are possible, while still making the flow clear.

Yeah, you can handle that :ok which you get in any case from my described function, but you can not handle the stuff happened at the other process state-data. Thats what I meant.

Remember: this :ok only tells you that sending a message to another process has been successful, NOT that the effectful operation on the other threads data has been successfull. It doesn’t even tell you which process you have send a message to…

It is just an atom, which by consensus means that some arbitrary operation has been successful, but you don’t have enough context to decide which one in this special case.

Fair enough