|
Why not `import Enum` to get rid of the redundant `Enum.` part? As imports are lexically scoped there is no need to worry about name clashes (e.g. Enum vs. Stream): import Enum
[1, 2, 3, 4]
|> filter(fn(n) -> rem(n, 2) == 0 end)
|> map(fn(n) -> n * n end)
|> reduce(0, fn(n, sum) -> sum + n end)
While we're at it, why not use a `&` operator to shorten the lambdas: import Enum
[1, 2, 3, 4]
|> filter( &(rem(&1, 2) == 0) )
|> map( &(&1 * &1) )
|> reduce(0, &(&1 + &2))
...is it that much worse than Ruby then? It's a bit different - the syntaxes are different, after all - but it doesn't look much worse, I think.Elixir, as well as Erlang, are peculiar languages. To achieve succinct code you need to phrase your code in a slightly different way, using pattern matching and guards, an occasional macro and alias/import commands (in Elixir's case). And the separation between the external interface and an internal implementation of any GenSomething is a valuable thing! Even if in most cases the external interface does relatively little, it's important to have them separated. That is because the external interface functions execute in the caller process, while the implementation code executes in the OTP process. If the caller submits an invalid value to be called/cast to your server, do you want to crash the caller or the server? With the usual pattern, you get to make this choice. And let's be honest - in the simplest case, it's three one-line functions (start, call, cast) per GenServer - it's not that bad of an overhead. There's also Agent module for when you don't need a full GenServer, using it eliminates all the overhead (in terms of lines of code) you normally get when using GenServer. |