Using Recursion in Elixir(rob.conery.io)
rob.conery.io
Using Recursion in Elixir
http://rob.conery.io/2015/09/04/using-recursion-in-elixir-to-break-your-oo-brain/
3 comments
The author seems confused, as the code here doesn't actually involve recursion. I wouldn't normally nitpick too hard, here, but he spends a lot of time talking about how Elixer made it possible for him to understand and use recursion... The trouble is neither of these things seemed to have happened...
I believe he is referencing the fact that the map_single function calls itself.
Gah, indeed it does! I pored over that code to find it and it was right there...
The post still seems to be more about pattern matching than recursion, but at least recursion is in there somewhere!
The post still seems to be more about pattern matching than recursion, but at least recursion is in there somewhere!
Actually, you are correct. There is no recursion.
It's perform pattern matching, the functions might have the same name, but it's not recursive, because they are different functions.
Let's pretend we can alias these functions using AS
fun1 calls fun2
fun2 calls fun3
fun4
to be recursive, a function must call itself or another function that calls it. neither of this is true. What the article is talking about is pattern matching.
Let's pretend we can alias these functions using AS
def map_single({:ok, res}) AS fun1
def map_single({:cols_and_first, cols, first_row}) AS fun2
def map_single({:zipped, list}) AS fun3
def map_single({:error, err}) AS fun4
fun1 calls fun2
fun2 calls fun3
fun4
to be recursive, a function must call itself or another function that calls it. neither of this is true. What the article is talking about is pattern matching.
Yup you're right. I thought they were mutually recursive but they're not.
I hate to be one of those that complain about the website itself and not the content but this one annoyed me greatly.
This site is another one that requires javascript to see any content for no apparent reason. Worse when scrolling on a narrow window (so that search is not on the right) like on a tablet, when you scroll up it jumps to the top rather than scrolling up so you lose where you are. When you scroll back down it jumps back to where it was so its hard to scroll up reliably.
Also regarding the content, I actually prefer the original code for some reason over the multitude of helper functions. But I guess that is a matter of style.
This site is another one that requires javascript to see any content for no apparent reason. Worse when scrolling on a narrow window (so that search is not on the right) like on a tablet, when you scroll up it jumps to the top rather than scrolling up so you lose where you are. When you scroll back down it jumps back to where it was so its hard to scroll up reliably.
Also regarding the content, I actually prefer the original code for some reason over the multitude of helper functions. But I guess that is a matter of style.
I'm sorry but that article is terrible. I don't even program in elixir, but if you are trying to don't even use this. There is no recursion, just pattern matching.
This kind of commentary is not welcome. The author of this post is learning and sharing his thoughts, i.e.: he closed the post with this comment:
> I know that there is a ton of room for improvement – so if you have a thought please share.
Sheesh.
> I know that there is a ton of room for improvement – so if you have a thought please share.
Sheesh.
Agreed on the tone, that's unnecessary. Even my own post is borderline... I'll edit it to fix that.
But this guy is ostensibly a professional. His CV lists a host of industry experience over the years.
And yet it seems he doesn't understand recursion? That's... Remarkable.
But this guy is ostensibly a professional. His CV lists a host of industry experience over the years.
And yet it seems he doesn't understand recursion? That's... Remarkable.
Serious question, is pattern matching in Elixir any different from overloading?
Pattern matching and function overloading based on types are different but can be used for the same purposes.
For function overloading the decision for which implementation to use usually happens at compile time along with the type checking. Pattern matching happens at runtime but is more powerful since you can pattern match based on you guessed it: patterns, instead of just types.
Another small difference is that with overloading multiple functions with different signatures are created (they just share name) but with pattern matching there is a single function with multiple "function clauses".
For function overloading the decision for which implementation to use usually happens at compile time along with the type checking. Pattern matching happens at runtime but is more powerful since you can pattern match based on you guessed it: patterns, instead of just types.
Another small difference is that with overloading multiple functions with different signatures are created (they just share name) but with pattern matching there is a single function with multiple "function clauses".
Great explanation. Thank you.
To provide a shorter answer: polymorphism dispatches on types at compile time. Pattern matching dispatches on values at runtime.