4 ms·

Erlang doesn't have loops. You've got filter, map, reduce, and recursion. It's safe to say for most programs that your Erlang solution is going to look rather d

Erlang doesn't have loops. You've got filter, map, reduce, and recursion. It's safe to say for most programs that your Erlang solution is going to look rather different than your ALGOL family one. And Java didn't, until relatively recently (oh god Java 8 was almost 10 years ago), have anonymous functions, which means that you'd be more inclined to express solutions in terms of vulgar loops rather than a map, filter, reduce type operation. Which is to say, they'd definitely look different.

nerdponx 4y ago
> 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.

nerdponx 4y ago

> 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.