4 ms·

Curious which languages you used. If they were C, C++, Java, and Python then I could see how they could blur together if you squint. Different syntax, similar s

Curious which languages you used. If they were C, C++, Java, and Python then I could see how they could blur together if you squint. Different syntax, similar semantics. But if those languages are C, APL, Erlang, ML and Lisp then I would expect the lesson would be the design space of languages is much larger than the popular imperative languages would have you believe.

dfinninger 4y ago
Sure, but in university that can be a useful exercise, whatever the language. There are many commonalities in just about every language. Learning your first language is hard, you’re second is freeing. At least personally I’ve found that the more languages I study, the easier it gets to pick up a new one, specifically because of the commonalities. Sure, Haskell and Ruby are really different, but when you try to pick up Elixir you’ve got a lot of common ground.
- goatlover 4y ago
  Languages like APL, Forth and Prolog are different enough that this wouldn't apply until you learn another array, stack, or logic-based language. And with languages like Smalltalk or Lisp, learning how to use the environment will be just as challenging.
nerdponx 4y ago
APL might be an outlier here. For the rest, I think the difference lies more in the standard libraries of those languages than the languages themselves. Yes, differences in core language design start to matter when you are considering performance, or structuring larger applications, but for simpler scripts, you're mostly dealing with the standard library. On the other hand, differences will start to show them selves after you spend a while noodling with your script, refactoring it a couple of times and deliberately seeking out opportunities to use language-specific features in the process. This expands the exercise to something more like "a language a week" instead of "a language of day", which is obviously a bit more of a time commitment. But if you want to get value out of a "polyglot" programming exercise like this, I think that's what you really need to do. Otherwise I think you learn lessons that are only correct at surface level.
- OkayPhysicist 4y ago
  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.

dfinninger 4y ago

Sure, but in university that can be a useful exercise, whatever the language. There are many commonalities in just about every language. Learning your first language is hard, you’re second is freeing. At least personally I’ve found that the more languages I study, the easier it gets to pick up a new one, specifically because of the commonalities. Sure, Haskell and Ruby are really different, but when you try to pick up Elixir you’ve got a lot of common ground.

goatlover 4y ago
Languages like APL, Forth and Prolog are different enough that this wouldn't apply until you learn another array, stack, or logic-based language. And with languages like Smalltalk or Lisp, learning how to use the environment will be just as challenging.

nerdponx 4y ago

APL might be an outlier here. For the rest, I think the difference lies more in the standard libraries of those languages than the languages themselves. Yes, differences in core language design start to matter when you are considering performance, or structuring larger applications, but for simpler scripts, you're mostly dealing with the standard library. On the other hand, differences will start to show them selves after you spend a while noodling with your script, refactoring it a couple of times and deliberately seeking out opportunities to use language-specific features in the process. This expands the exercise to something more like "a language a week" instead of "a language of day", which is obviously a bit more of a time commitment. But if you want to get value out of a "polyglot" programming exercise like this, I think that's what you really need to do. Otherwise I think you learn lessons that are only correct at surface level.

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