5 ms·

> Really confused by the downvotes It's not type safe. Any other modern/static language would use generics to ensure inSlice and mapperFn both operate on the s

> Really confused by the downvotes It's not type safe. Any other modern/static language would use generics to ensure inSlice and mapperFn both operate on the same types. People downvoting you probably see this as obvious for programmers that want/choose a static language like Go/Java/TypeScript/etc.

daenz 8y ago
>It's not type safe. Yes, I get that, but that's also moving the goalpost. The post claimed that "you can’t write a generic map from an array of T to an array of R", but you can (if you take generic to mean "general" and not "specifically using the mechanism of generics"). I think the author just didn't know that this was possible, or his concern would have been about the lack of type safety with the reflection method.
- nostalgeek 8y ago
  > Yes, I get that, but that's also moving the goalpost. no it is not. The whole point of generic programming is compile time type safety for incomplete types. > but you can (if you take generic to mean "general" and not "specifically using the mechanism of generics"). not in a compile time type safe way. Again, you can't negate the whole point of generics, that's a cop-out. You just wrote Python like dynamic code in Go here, with reflection (AKA runtime behavior) which incures a severe performance penalty. And let's not get started on the fact that you're returning []interface{} which is often pretty useless when the type of the element matters. You introduced some serious code smell with that function since you threw away type safety. If you really want to write a generic mapper the only serious way to do that in go is to use reflect.MakeFunc then a function variable of the choosen signature. But again reflection is so slow it's not even worth to begin with.
  - daenz 8y ago
    >no it is not. The whole point of generic programming is compile time type safety for incomplete types. Except that's not what the post's gripe was about. His gripe was that you need to write a new function for every type you want to map, because there's no way to write one that is generic for all types. He doesn't mention type safety at all, so yes, the solution I posted meets the goal of his complaint. >And let's not get started on the fact that you're returning []interface{} which is often pretty useless when the type of the element matters. You introduced some serious code smell with that function since you threw away type safety. Did you miss the point where I said "it's not good or pretty" ? Or do you just want to bitch about everything? Your whole post reads like someone who has never written a container type in Go. Guess how you do it? You use interface{} and cast in the caller!
    - nostalgeek 8y ago
      > Did you miss the point where I said "it's not good or pretty" ? Or do you just want to bitch about everything? I'm not bitching about anything (you don't need to use this kind of language here, it is not reddit), I'm telling you that piece of code you wrote is pretty useless. It is not compile time type safe and it is slow due to the use of reflection. This is not an alternative to generics or generic functions in the language. It fixes nothing.
      - daenz 8y ago
        >This is not an alternative to generics or generic functions in the language. It fixes nothing. When it comes to Go, you don't know what you're talking about. Learn to write a container type and then get back to me. Here's a Heap https://golang.org/src/container/heap/heap.go?s=2105:2138#L51 https://golang.org/src/container/heap/heap.go?s=2105:2138#L5... See the return type? interface{}. This is how it's done in Go. How did you think it was done without generics? IntHeap, StringHeap, FloatHeap, etc? "You can't do X because Go doesn't have Y" was the original point. My response was "you do X with Z." Whether or not Z is good or bad is completely orthogonal to the original point seeing as how it's idiomatic in Go.
        piano 8y ago
        > "You can't do X because Go doesn't have Y" was the original point. My response was "you do X with Z." Whether or not Z is good or bad is completely orthogonal to the original point seeing as how it's idiomatic in Go. No, it's not orthogonal. The part you cited even mentions strong typing, thereby IMO it is pretty obvious type-safety is a requirement here. Otherwise what would even be the point of the exercise? Mapping of some data to some other data? You can do that in _any_ turing-complete language. The comment said "you can’t write a generic map from an array of T to an array of R" and, indeed, you can't do that in Go. Your code maps a slice of dynamic values to a slice of dynamic values. It doesn't map array of T to array of R, as requested, because there's simply no way to express that in Go. Besides, I think think it even actually _is_ idiomatic since you used reflection.

daenz 8y ago

>It's not type safe. Yes, I get that, but that's also moving the goalpost. The post claimed that "you can’t write a generic map from an array of T to an array of R", but you can (if you take generic to mean "general" and not "specifically using the mechanism of generics"). I think the author just didn't know that this was possible, or his concern would have been about the lack of type safety with the reflection method.

nostalgeek 8y ago
> Yes, I get that, but that's also moving the goalpost. no it is not. The whole point of generic programming is compile time type safety for incomplete types. > but you can (if you take generic to mean "general" and not "specifically using the mechanism of generics"). not in a compile time type safe way. Again, you can't negate the whole point of generics, that's a cop-out. You just wrote Python like dynamic code in Go here, with reflection (AKA runtime behavior) which incures a severe performance penalty. And let's not get started on the fact that you're returning []interface{} which is often pretty useless when the type of the element matters. You introduced some serious code smell with that function since you threw away type safety. If you really want to write a generic mapper the only serious way to do that in go is to use reflect.MakeFunc then a function variable of the choosen signature. But again reflection is so slow it's not even worth to begin with.
- daenz 8y ago
  >no it is not. The whole point of generic programming is compile time type safety for incomplete types. Except that's not what the post's gripe was about. His gripe was that you need to write a new function for every type you want to map, because there's no way to write one that is generic for all types. He doesn't mention type safety at all, so yes, the solution I posted meets the goal of his complaint. >And let's not get started on the fact that you're returning []interface{} which is often pretty useless when the type of the element matters. You introduced some serious code smell with that function since you threw away type safety. Did you miss the point where I said "it's not good or pretty" ? Or do you just want to bitch about everything? Your whole post reads like someone who has never written a container type in Go. Guess how you do it? You use interface{} and cast in the caller!
  - nostalgeek 8y ago
    > Did you miss the point where I said "it's not good or pretty" ? Or do you just want to bitch about everything? I'm not bitching about anything (you don't need to use this kind of language here, it is not reddit), I'm telling you that piece of code you wrote is pretty useless. It is not compile time type safe and it is slow due to the use of reflection. This is not an alternative to generics or generic functions in the language. It fixes nothing.
    - daenz 8y ago
      >This is not an alternative to generics or generic functions in the language. It fixes nothing. When it comes to Go, you don't know what you're talking about. Learn to write a container type and then get back to me. Here's a Heap https://golang.org/src/container/heap/heap.go?s=2105:2138#L51 https://golang.org/src/container/heap/heap.go?s=2105:2138#L5... See the return type? interface{}. This is how it's done in Go. How did you think it was done without generics? IntHeap, StringHeap, FloatHeap, etc? "You can't do X because Go doesn't have Y" was the original point. My response was "you do X with Z." Whether or not Z is good or bad is completely orthogonal to the original point seeing as how it's idiomatic in Go.
      - piano 8y ago
        > "You can't do X because Go doesn't have Y" was the original point. My response was "you do X with Z." Whether or not Z is good or bad is completely orthogonal to the original point seeing as how it's idiomatic in Go. No, it's not orthogonal. The part you cited even mentions strong typing, thereby IMO it is pretty obvious type-safety is a requirement here. Otherwise what would even be the point of the exercise? Mapping of some data to some other data? You can do that in _any_ turing-complete language. The comment said "you can’t write a generic map from an array of T to an array of R" and, indeed, you can't do that in Go. Your code maps a slice of dynamic values to a slice of dynamic values. It doesn't map array of T to array of R, as requested, because there's simply no way to express that in Go. Besides, I think think it even actually _is_ idiomatic since you used reflection.