Simple apply/filter/reduce package in Go • Hacker News Board

Re: Simple apply/filter/reduce package in Go

#31

Post by masklinn » Fri, Apr 03, 2015, 2:26 PM UTC

hyperpape wrote: post #19

falcolas wrote: post #2

But you can't write generic functions in Go! Oh, wait. He just did. As a caveat to my exasperated sarcasm, I do realize he's using reflection to identify and type the data at runtime, as opposed to compile time as with C++ templating, but this is kind of generalization is still quite useful when writing general purpose library code. Personally, I'd not be inclined to use this either, the number of times I've actually…

This only handles functions of type a -> a -> a ( https://github.com/robpike/filter/blob/master/reduce.go ), whereas a generic reduce takes functions of type a -> a -> b. So this is certainly not proof that you can write generics in go. See also pmahoney's comment in this thread: https://news.ycombinator.com/item?id=9315721 .

And even with that, it still returns an interface{} which you need to cast.

Re: Simple apply/filter/reduce package in Go

#32

Post by eropple » Fri, Apr 03, 2015, 2:37 PM UTC

seanmcdirmid wrote: post #21

eropple wrote: post #17

Earlier quoted context omitted.

I was pretty confused by this post for a minute until I remembered I've been on VS2015 since the first preview release. This problem is greatly reduced there.

I saw that in June, and I'm interested in how effective it is, and what the usability characteristics are (it looked complex at the time, but it was an early demo). But going from 2010 to 2013 was a painful, and I don't want to throw this in a VM, so I'll just wait for RTM.

2013 to 2015 is a much smaller jump. Unless you are doing weirder things than me (and I mean, that's kind of hard!), I'd bet you'd be party. YMMV, of course.

Re: Simple apply/filter/reduce package in Go

#33

Post by falcolas » Fri, Apr 03, 2015, 2:39 PM UTC

TheCoelacanth wrote: post #29

falcolas wrote: post #2

But you can't write generic functions in Go! Oh, wait. He just did. As a caveat to my exasperated sarcasm, I do realize he's using reflection to identify and type the data at runtime, as opposed to compile time as with C++ templating, but this is kind of generalization is still quite useful when writing general purpose library code. Personally, I'd not be inclined to use this either, the number of times I've actually…

It's 30 lines long (the equivalent in Haskell would be 1 fairly simple line of code). Type errors are detected at runtime instead of at compile type, and it's not as generic as actual reduce.

> It's 30 lines long (the equivalent in Haskell would be 1 fairly simple line of code).

Bully for Haskell. Language N can always do it better/faster/shorter than language M. What matters in this case is that it can be done, in a type safe way.

> Type errors are detected at runtime instead of at compile type

Already mentioned that.

> it's not as generic as actual reduce.

It's toy code, forgive him for not writing it perfectly. If it can accept one ambiguous type throughout, there's no reason it could not accept multiple types throughout.

Re: Simple apply/filter/reduce package in Go

#34

Post by bunderbunder » Fri, Apr 03, 2015, 2:46 PM UTC

adrusi wrote: post #22

drcode wrote: post #8

Earlier quoted context omitted.

That's the essence of Clojure's transducers http://clojure.org/transducers ...they give you the declarative syntax of filter/reduce/etc but can have the same evaluation strategy as for loops, with comparable performance.

That's not why clojure has transducers. You can use a mapping transducer to express map, but it's actually going to have slightly worse performance than regular map. There's nothing inherently slow about higher order collection functions, rust has them and they compile to the same machine code as the equivalent loop construct. Its just that most languages implement them on the wrong data structures. Functional langua…

.NET implements them on iterators, too, but that's not an inherently fast approach. .NET iterators are objects that implement a specific interface, and iterating over them involves two function calls per element - one to move to the next item, and one to retrieve the current item.

Those two function calls introduce an overhead that may be significant in a "tight loop", and that may not exist in a hand-coded for loop.

Perhaps .NET's optimizer is smart enough to get things down to a for loop equivalent in some cases, but in general I haven't seen much evidence of that happening.

Re: Simple apply/filter/reduce package in Go

#35

Post by metaphorm » Fri, Apr 03, 2015, 2:50 PM UTC

kasabali wrote: post #20

metaphorm wrote: post #10

Earlier quoted context omitted.

filter and reduce are both builtins in Python and I see nothing discouraging anyone from taking full advantage of them.

GvR discourages them if that's a strong enough reason for you :)

its not, actually. he seems to discourage them on the grounds that a list comprehension would be better. however, that's just alternate syntax for a logically equivalent operation. personally, I use whichever one is more clear to me based on context. I appreciate having the option. Maybe you say that's un-Pythonic because "there should be just one way to do things", but I'm not particularly dogmatic and not persuaded by that.

Re: Simple apply/filter/reduce package in Go

#36

Post by falcolas » Fri, Apr 03, 2015, 2:52 PM UTC

hyperpape wrote: post #19

falcolas wrote: post #2

But you can't write generic functions in Go! Oh, wait. He just did. As a caveat to my exasperated sarcasm, I do realize he's using reflection to identify and type the data at runtime, as opposed to compile time as with C++ templating, but this is kind of generalization is still quite useful when writing general purpose library code. Personally, I'd not be inclined to use this either, the number of times I've actually…

This only handles functions of type a -> a -> a ( https://github.com/robpike/filter/blob/master/reduce.go ), whereas a generic reduce takes functions of type a -> a -> b. So this is certainly not proof that you can write generics in go. See also pmahoney's comment in this thread: https://news.ycombinator.com/item?id=9315721 .

> This only handles functions of type a -> a -> a

So, since his toy code was explicitly written to accept the same type for both parameters of the function, you are unable to see how it could be modified to accept a different type signature for the reduce function? It looks to me like a fairly trivial change to get the type of argument `zero`, and use that as one of the parameters to the reduce function.

As for pmahoney's comment, looks like there's a bug. Perhaps he should file a bug report, or pull request.

Re: Simple apply/filter/reduce package in Go

#37

Post by EugeneOZ » Fri, Apr 03, 2015, 2:52 PM UTC

With so many "interface{}"s Go looks more like weakly-typed.

"Apply takes a slice of type []T and a function of type func(T) T"

And after that golang.org docs are saying "We don't feel an urgency for them" about generics"...

Re: Simple apply/filter/reduce package in Go

#38

Post by falcolas » Fri, Apr 03, 2015, 2:54 PM UTC

pmahoney wrote: post #13

This isn't "reduce" as I know it. It requires the user function return the same data type as contained by the slice. Furthermore, for a slice of size 1, it simply returns that single element. case 1: return in.Index(0) ... if !goodFunc(fn, elemType, elemType, elemType) { ... panic } So I could not, for example, reduce a slice of numbers into a struct of (min,max,mean).

Not with this specific implementation. However, it would be fairly trivial to substitute one of the elemType arguments with the type of `zero`.

Perhaps a pull request is in order?

Re: Simple apply/filter/reduce package in Go

#39

Post by falcolas » Fri, Apr 03, 2015, 2:57 PM UTC

EugeneOZ wrote: post #37

With so many "interface{}"s Go looks more like weakly-typed. "Apply takes a slice of type []T and a function of type func(T) T" And after that golang.org docs are saying "We don't feel an urgency for them" about generics"...

Looks are deceiving. `interface{}` != `void *`. The value inside the `interface{}` box is still strongly typed, it's just boxed to make function interfaces simpler (given Go's lack of generics).

Re: Simple apply/filter/reduce package in Go

#40

Post by drcode » Fri, Apr 03, 2015, 2:57 PM UTC

adrusi wrote: post #22

drcode wrote: post #8

Earlier quoted context omitted.

That's the essence of Clojure's transducers http://clojure.org/transducers ...they give you the declarative syntax of filter/reduce/etc but can have the same evaluation strategy as for loops, with comparable performance.

That's not why clojure has transducers. You can use a mapping transducer to express map, but it's actually going to have slightly worse performance than regular map. There's nothing inherently slow about higher order collection functions, rust has them and they compile to the same machine code as the equivalent loop construct. Its just that most languages implement them on the wrong data structures. Functional langua…

> You can use a mapping transducer to express map, but it's actually going to have slightly worse performance than regular map.

That's a strawman argument- Neither OP nor my comment made any mention of "map". This is a discussion about reduction and filtering. Yes, using transducers in a way that is silly like you suggest will produce disappointing results.