6 ms·

A lot of functional constructs heavily rely on parametric polymorphism. For example: map :: (a -> b) -> [a] -> [b] Interfaces can't provide this type of c

A lot of functional constructs heavily rely on parametric polymorphism. For example: map :: (a -> b) -> [a] -> [b] Interfaces can't provide this type of code reuse.

DanWaterworth 14y ago
Slight nitpick, you can do this, just not with type safety. Type safety is the real reason generics are better than interfaces.
mseepgood 14y ago
If you're attached to FP style you shouldn't choose an imperative language in the first place.
- jerf 14y ago
  It has been pretty conclusively demonstrated at this point that a basic suite of "weak" FP tools is pretty useful in any language. No serious modern language should try to work without convenient closures and a functioning map and filter statement/function/whatever. This hasn't got anything to do with purity or academic goodness, and everything to do with the fact that languages like Python or Ruby, which are emphatically not FP languages, have simply shown such things to be indispensable tools for concise code.
  - eckyptang 14y ago
    Pretty useful: yes. Essential: no. Map/Filter introduce several new semantic concepts to a language. I think they were avoided for simplicity's sake and the fact you can achieve the same result with a for loop, even if it is slightly less concise.
    - masklinn 14y ago
      > Map/Filter introduce several new semantic concepts to a language. No they don't. If you already have first-class functions (Go does) and some sort of sequence type (Go does), you have map/filter. There's no new semantic concepts.
    - nephesh 14y ago
      With this standard for "essential" you may as well just drop down into assembly language. The only added simplicity here is for the compiler writers, not the end users.
      - mseepgood 14y ago
        numbers = map(numbers, func(n int) int { return n * n }) for i, n := range numbers { numbers[i] = n * n } Sorry, but I do not see a difference in the order of assembly language vs. high-level language.
        nephesh 14y ago
        Now try it on a more complex type. Then try and compose various operations. Then swap out the container type.
        mseepgood 14y ago
        (Unfortunately, formatting is lost) a) With a more complex type (I don't see how this would affect one more than the other) Functional would be: foos = map(foos, func(f Foo) Foo { return Foo{f.A * f.A, f.B * f.B} }) Iterative is: for i, f := range foos { foos[i] = Foo{f.A * f.A, f.B * f.B} } b) Composing various operations. Composing filter + map: Functional would be: x := filter(map(numbers, func(n int) int { return n * n }), func(n int) bool { return n % 2 == 0 }) Iterative is: x := make([]int, 0); for _, n := range numbers { sq := n * n; if sq % 2 == 0 { x = append(x, sq) } } c) Swapping the container type is just a matter of swapping "_, n := range numbers".
        nephesh 14y ago
        > With a more complex type (I don't see how this would affect one more than the other) It does because the discussion is about generics. The fact that you're writing out types for one and not the other makes your comparisons a bit disingenuous, though I understand if Go isn't very good at functional programming. b) Composing various operations. Composing filter + map: As you keep building them up the imperative style will have more code overhead and less efficiency. > c) Swapping the container type is just a matter of swapping "_, n := range numbers". This isn't true since the functional one could easily swap out to use an infinite data source whereas the imperative will be constrained to the arrays you're already using.
- papsosouid 14y ago
  We're WAY past the point where it is acceptable to pretend basics like map and filter are some esoteric functional thing. Every reasonable language has them, and no language without them is worth even considering.
  - eckyptang 14y ago
    map and filter are no problem: https://github.com/tcard/functional https://github.com/tcard/functional I can't say I've actually needed to use map or filter. You can, much as people did for the last 30 years and still do with C, quite happily do this sort of stuff with a for loop...
    - papsosouid 14y ago
      People spent years without loops too, "quite happily" doing it with jumps. Lacking useful abstractions is not a case of preference, it is being inferior.

A lot of functional constructs heavily rely on parametric polymorphism. For example: map :: (a -> b) -> [a] -> [b] Interfaces can't provide this type of code reuse.

DanWaterworth 14y ago

Slight nitpick, you can do this, just not with type safety. Type safety is the real reason generics are better than interfaces.

mseepgood 14y ago

If you're attached to FP style you shouldn't choose an imperative language in the first place.

jerf 14y ago
It has been pretty conclusively demonstrated at this point that a basic suite of "weak" FP tools is pretty useful in any language. No serious modern language should try to work without convenient closures and a functioning map and filter statement/function/whatever. This hasn't got anything to do with purity or academic goodness, and everything to do with the fact that languages like Python or Ruby, which are emphatically not FP languages, have simply shown such things to be indispensable tools for concise code.
- eckyptang 14y ago
  Pretty useful: yes. Essential: no. Map/Filter introduce several new semantic concepts to a language. I think they were avoided for simplicity's sake and the fact you can achieve the same result with a for loop, even if it is slightly less concise.
  - masklinn 14y ago
    > Map/Filter introduce several new semantic concepts to a language. No they don't. If you already have first-class functions (Go does) and some sort of sequence type (Go does), you have map/filter. There's no new semantic concepts.
  - nephesh 14y ago
    With this standard for "essential" you may as well just drop down into assembly language. The only added simplicity here is for the compiler writers, not the end users.
    - mseepgood 14y ago
      numbers = map(numbers, func(n int) int { return n * n }) for i, n := range numbers { numbers[i] = n * n } Sorry, but I do not see a difference in the order of assembly language vs. high-level language.
      - nephesh 14y ago
        Now try it on a more complex type. Then try and compose various operations. Then swap out the container type.
        mseepgood 14y ago
        (Unfortunately, formatting is lost) a) With a more complex type (I don't see how this would affect one more than the other) Functional would be: foos = map(foos, func(f Foo) Foo { return Foo{f.A * f.A, f.B * f.B} }) Iterative is: for i, f := range foos { foos[i] = Foo{f.A * f.A, f.B * f.B} } b) Composing various operations. Composing filter + map: Functional would be: x := filter(map(numbers, func(n int) int { return n * n }), func(n int) bool { return n % 2 == 0 }) Iterative is: x := make([]int, 0); for _, n := range numbers { sq := n * n; if sq % 2 == 0 { x = append(x, sq) } } c) Swapping the container type is just a matter of swapping "_, n := range numbers".
        nephesh 14y ago
        > With a more complex type (I don't see how this would affect one more than the other) It does because the discussion is about generics. The fact that you're writing out types for one and not the other makes your comparisons a bit disingenuous, though I understand if Go isn't very good at functional programming. b) Composing various operations. Composing filter + map: As you keep building them up the imperative style will have more code overhead and less efficiency. > c) Swapping the container type is just a matter of swapping "_, n := range numbers". This isn't true since the functional one could easily swap out to use an infinite data source whereas the imperative will be constrained to the arrays you're already using.
papsosouid 14y ago
We're WAY past the point where it is acceptable to pretend basics like map and filter are some esoteric functional thing. Every reasonable language has them, and no language without them is worth even considering.
- eckyptang 14y ago
  map and filter are no problem: https://github.com/tcard/functional https://github.com/tcard/functional I can't say I've actually needed to use map or filter. You can, much as people did for the last 30 years and still do with C, quite happily do this sort of stuff with a for loop...
  - papsosouid 14y ago
    People spent years without loops too, "quite happily" doing it with jumps. Lacking useful abstractions is not a case of preference, it is being inferior.