4 ms·

> You've got filter, map, reduce, and recursion. Right, and you can implement a recursive function in Haskell, OCaml, or Scheme that looks more or less identic

> You've got filter, map, reduce, and recursion. Right, and you can implement a recursive function in Haskell, OCaml, or Scheme that looks more or less identical in all 3 languages, and is only a recursion-transformation away from the for-loop version seen in Python, Ruby, Java, etc. So all the functional recursion-based implementations will look similar, and all the imperative loop-based implementations will look similar, and the two classes of implementations will also have a lot of overarching similarity. The basic pattern of "obtain system state, do thing, set up next system state, proceed to next thing" is the same. The differences between languages (read: sets of tools that you are given for expressing algorithms) tend not to become apparent until you've spent a little while working with them. I can't speak specifically to Erlang because I haven't used it, but from what I've seen the story should be the same.

OkayPhysicist 4y ago
The semantics of a language shape its use in practice, though. For example: If you're in a language that primarily uses recursion as the primary iteration mechanism, if you have to iterate through every element of a tree you will just about never do a breadth-first search unless it is absolutely necessary. It's just a pain to express recursively compared to a depth-first traversal. In contrast, in an iterative language, a breadth first traversal is the same (somewhat obnoxious) complexity as any other traversal. But that's assuming both languages would be traversing a tree at all: trees are vastly more likely to be used at all in languages where recursion is the norm. Like, sure, any iterative function of the form: f(x) = { state = h(x) cond = true while(cond) do state = j(x,state) cond = k(x,state) end post_work = l(state,x) return post_work } Can be re-written as f(x) = l(m(x,h(x))) m(x,state) = state if k(x,state) else m(x,j(x,state)) But if your language only supports one or the other, you're going to approach the problem in fundamentally different ways. Whereas the iterative solution is likely to jump directly into the loop with a trivial h(), the functional language is far more likely to do more work in h() to offload work out of j() prior to what would likely end up being a fold operation. Put another way: for(i=0;i<x;i++) loops are common in iterative codebases I've worked on, but it's exceedingly rare to see f(x,i) = blah return f(g(x),i++) in a functional codebase.

OkayPhysicist 4y ago

The semantics of a language shape its use in practice, though. For example: If you're in a language that primarily uses recursion as the primary iteration mechanism, if you have to iterate through every element of a tree you will just about never do a breadth-first search unless it is absolutely necessary. It's just a pain to express recursively compared to a depth-first traversal. In contrast, in an iterative language, a breadth first traversal is the same (somewhat obnoxious) complexity as any other traversal. But that's assuming both languages would be traversing a tree at all: trees are vastly more likely to be used at all in languages where recursion is the norm. Like, sure, any iterative function of the form: f(x) = { state = h(x) cond = true while(cond) do state = j(x,state) cond = k(x,state) end post_work = l(state,x) return post_work } Can be re-written as f(x) = l(m(x,h(x))) m(x,state) = state if k(x,state) else m(x,j(x,state)) But if your language only supports one or the other, you're going to approach the problem in fundamentally different ways. Whereas the iterative solution is likely to jump directly into the loop with a trivial h(), the functional language is far more likely to do more work in h() to offload work out of j() prior to what would likely end up being a fold operation. Put another way: for(i=0;i<x;i++) loops are common in iterative codebases I've worked on, but it's exceedingly rare to see f(x,i) = blah return f(g(x),i++) in a functional codebase.