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

Re: Simple apply/filter/reduce package in Go

#11

Post by mhd » Fri, Apr 03, 2015, 1:29 PM UTC

inglor wrote: post #4

I don't get why someone would rather write a for loop than use declarative data syntax. If I want to get the names of all administrators doing `users.Where(user => user.isAdmin()).Select(user => user.Name)` is so much nicer than using a for loop - or maybe he's suggesting we start writing FOR loops instead of SQL for our databases too?

Wasn't one of Pike's earliest published whitepapers basically stating that "most of what you need is binary trees, linked lists and hashes" when it came to data structures/algorithms? (Probably add CSP to that list, given his prior work)

So I'd dare to say he's a bit of a minimalist. Fanboys and fellow travelers aside, one of the few persons with a similar point of view that I can think of would be Niklaus Wirth.

But that's the luxury that research and academia offer to you, if your problems can be approach from a tabula rasa view, you can tailor your tools to be similary pure (his "pure" obviously not being of the mathematical/functional persuasion).

I mean, there's no solid reason why we have several different kinds of screwdrivers. But that doesn't help you when you have to assemble your IKEA Wöbsörwös furniture to earn your living.

Re: Simple apply/filter/reduce package in Go

#12

Post by svisser » Fri, Apr 03, 2015, 1:29 PM UTC

metaphorm wrote: post #10

svisser wrote: post #7

Earlier quoted context omitted.

It's easy to dismiss an opinion but that doesn't mean it's wrong. For example, if you like filter/reduce you may criticize languages that don't encourage it (Go, Python, etc). But often this leads to copying ideas from one language resulting in code that's hard to maintain in another language which encourages different ways of expressing the same logic.

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

In Python 3 reduce was removed and you'd have to use functools.reduce. Similarly lambda functions are a bit of a mistake, in Guido's opinion, as well as his preference to use list comprehensions over filter(). I don't expect to see more functional programming constructs anytime soon in Python. That being said, list comprehensions work quite well in Haskell, Python, etc.

Re: Simple apply/filter/reduce package in Go

#13

Post by pmahoney » Fri, Apr 03, 2015, 1:30 PM UTC

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

Re: Simple apply/filter/reduce package in Go

#14

Post by [deleted] » Fri, Apr 03, 2015, 1:31 PM UTC

metaphorm wrote: post #10

svisser wrote: post #7

Earlier quoted context omitted.

It's easy to dismiss an opinion but that doesn't mean it's wrong. For example, if you like filter/reduce you may criticize languages that don't encourage it (Go, Python, etc). But often this leads to copying ideas from one language resulting in code that's hard to maintain in another language which encourages different ways of expressing the same logic.

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

[deleted]

Re: Simple apply/filter/reduce package in Go

#15

Post by fosforsvenne » Fri, Apr 03, 2015, 1:36 PM UTC

mhd wrote: post #11

inglor wrote: post #4

I don't get why someone would rather write a for loop than use declarative data syntax. If I want to get the names of all administrators doing `users.Where(user => user.isAdmin()).Select(user => user.Name)` is so much nicer than using a for loop - or maybe he's suggesting we start writing FOR loops instead of SQL for our databases too?

Wasn't one of Pike's earliest published whitepapers basically stating that "most of what you need is binary trees, linked lists and hashes" when it came to data structures/algorithms? (Probably add CSP to that list, given his prior work) So I'd dare to say he's a bit of a minimalist. Fanboys and fellow travelers aside, one of the few persons with a similar point of view that I can think of would be Niklaus Wirth. But…

The letter W isn't used in Swedish except in proper names and the occasional loanword.

Re: Simple apply/filter/reduce package in Go

#16

Post by adrusi » Fri, Apr 03, 2015, 1:37 PM UTC

inglor wrote: post #4

I don't get why someone would rather write a for loop than use declarative data syntax. If I want to get the names of all administrators doing `users.Where(user => user.isAdmin()).Select(user => user.Name)` is so much nicer than using a for loop - or maybe he's suggesting we start writing FOR loops instead of SQL for our databases too?

Because for loops are special forms to the compiler and don't require general parametric polymorphism to be implemented in the language. Parametric polymorphism adds a lot of complexity to the language, so I guess the go team has decided to just not have it in the language. I'm not sure I agree with that decision, but it is true that parametric polymorphism isn't all that useful for the types of programs go is usually used for.

You don't want to use this implementation because it uses reflection, which makes it slow and means the compiler can't catch your errors.

Re: Simple apply/filter/reduce package in Go

#17

Post by eropple » Fri, Apr 03, 2015, 1:40 PM UTC

seanmcdirmid wrote: post #9

inglor wrote: post #4

I don't get why someone would rather write a for loop than use declarative data syntax. If I want to get the names of all administrators doing `users.Where(user => user.isAdmin()).Select(user => user.Name)` is so much nicer than using a for loop - or maybe he's suggesting we start writing FOR loops instead of SQL for our databases too?

Debugging. Try debugging a Select/Where stream in C#; it is a PITA. I often find myself unwinding my list comprehensions into for loops because I need to debug. There is a reason Haskell's type system has to be so strong :)

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.

Re: Simple apply/filter/reduce package in Go

#18

Post by mhd » Fri, Apr 03, 2015, 1:41 PM UTC

fosforsvenne wrote: post #15

mhd wrote: post #11

Earlier quoted context omitted.

Wasn't one of Pike's earliest published whitepapers basically stating that "most of what you need is binary trees, linked lists and hashes" when it came to data structures/algorithms? (Probably add CSP to that list, given his prior work) So I'd dare to say he's a bit of a minimalist. Fanboys and fellow travelers aside, one of the few persons with a similar point of view that I can think of would be Niklaus Wirth. But…

The letter W isn't used in Swedish except in proper names and the occasional loanword.

And just when I felt so smart about using "ö" and not "ø" for fake furniture…

Re: Simple apply/filter/reduce package in Go

#19

Post by hyperpape » Fri, Apr 03, 2015, 1:41 PM UTC

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.

Re: Simple apply/filter/reduce package in Go

#20

Post by kasabali » Fri, Apr 03, 2015, 1:44 PM UTC

metaphorm wrote: post #10

svisser wrote: post #7

Earlier quoted context omitted.

It's easy to dismiss an opinion but that doesn't mean it's wrong. For example, if you like filter/reduce you may criticize languages that don't encourage it (Go, Python, etc). But often this leads to copying ideas from one language resulting in code that's hard to maintain in another language which encourages different ways of expressing the same logic.

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 :)