The problem of having many small functions is that then you need to name many small functions. As we all know, naming things is one of the two hard problems in computer science.
derek-zhou
D4no0
Then this should a better vector to focus on fixing instead of introducing early returns into the codebase, because while you will be able to use them correctly, someone else will come and create some abominations that nor you or your teammates will understand.
If you and your team have the time and resources, I would suggest to try to refine what means the clarity of the code at a cultural level in the company, and enforce some good practices to adhere to, much like credo does at the moment, a good place to start is this talk: https://www.youtube.com/watch?v=6sNmJtoKDCo
2
cjbottaro
The inheritance problem doesn’t exist in Elixir, but the billions of tiny functions problem does (or can). I feel that with contributes to the latter in a lot of cases and early returns lets me simply have larger functions where I can do my business logic inline without factoring out into 1-use functions.
I feel like this is a style/opinion debate at this point, though I appreciate and agree with your notion of using return to break out of enumerations is not good in a functional language.
I’m still curious about the “nonlocal return” problem. I don’t understand that.
1
D4no0
Yes, but there are other things that exist, especially when coming from OOP and mutable languages, mainly defensive code style (witch can be a huge factor in this problem you are having).
In my 4 years of elixir development I never saw a need for early returns, expect when I was starting with elixir, I was always fighting credo and one of the things that is nice there is that its configured to not allow more than 3 nested conditionals in a function. As for small functions, I absolutely never had the problem of having too many of them, this is especially true when you create the functions locally for the module.
1
al2o3cr
Here’s a hypothetical example (hypothetical because I’m guessing how returnable works):
def some_function(arg1, arg2) do
returnable do
v1 = some_other_function(arg1)
{:ok, v1}
end
end
def some_other_function(arg1) do
2 * yet_another_function(arg1)
end
def yet_another_function(arg1) do
if arg1 < 123_456 do
return :nope
else
arg1 - 123_456
end
end
yet_another_function calls return (which I assume calls throw) so the stack is unwound all the way back to some_function, instead of doing an early-return from yet_another_function to some_other_function.
There’s an interesting parallel situation in Ruby with break and do blocks. It’s legal to do this:
some_array.map do |el|
if el == "nope"
break "nope"
else
el.upcase
end
end
The result is that the break statement terminates the map and makes the whole expression return the supplied value ("nope" here), similar to how the returnable return behaves.
However, this code is not allowed by the parser:
def break_helper(arg)
break arg
end
some_array.map do |el|
if el == "nope"
break_helper(el)
else
el.upcase
end
end
Attempting to define break_helper produces a SyntaxError:
SyntaxError: (irb):26: Invalid break
from (irb)
The rule is pretty much “you can’t say break unless the parser can see the block it breaks out of” - which would help make returnable clearer for users at the cost of a LOT of additional macro-juggling for the implementer.
2
cjbottaro
Ohhh, I see. And ha, that’s exactly why it’s wrapped up in a little lib… you cannot call return from outside a returnable block.
Further, each returnable block has its own unique id, and a call to return inside that block will throw that unique id. I’m not sure if that’s overkill or not, but ehh, it was a fun little dive into metaprogramming.
1
matt-savvy
lpil
Creator of Gleam
I’m surprised that there’s not any mention of function combinators such as map and bind/try/then, as is common in other functional languages. They can implement the same patterns as early returns but don’t require any special new language functionality, and they’re trivial for the programmer to extent. They work with pipes, or with a feature like Gleam’s use and OCaml’s let operators it can look very familiar too.
pub fn reply(message) {
use <- guard(is_uppercase(message), return: Error(Rude))
use <- guard(message == "", return: Error(Quiet))
use name <- try(get_name())
Ok("Hello, " <> name)
}
1
hst337
Because in Elixir there are no such combinators. Well, technically there are, but their runtime overhead is too big for anything serious
1
lpil
Creator of Gleam
Neither of these are true. The overhead of a function call is very small on the BEAM (if it wasn’t modules of nothing but combinators like Enum wouldn’t be usable), and there are multiple result combinator libraries for Elixir.
1