The problem is that you would need to rewrite that code for each type of foo and bar.... so if you have a set of ints and a set of strings and a set of SomeStruct... they'd all need their own implementation.

This is where code generation can work really well, especially for boring crap like set functionality... but he's right that rewriting it each time you figure out you have a new set type is a pain in the butt.

If the base type of the set is a bit set, the function need only worry about the position of each bit, and not the intended type. Of course, if the set has content in hash buckets (or a similar scheme), you would need to pass in some kind of comparator function/callback.

I say this as a former C programmer used to doing such things to make library routines like "bsearch()" work.

Too many things in Java rely on subclassing, rather than functional composition.

What is the (declared) type of `SetUnion`? Don't forget, Go has no generics/parametric polymorphism.

So, are you saying that it's impossible to declare a function without generics? How did the world run before generics were invented?

> How did the world run before generics were invented?

We used code-generators or pre-compiler macros or dynamically typed languages or we hand-wrote heaps upon heaps of boilerplate.

It sucked.

And regardless, Go only offers the last option.

The author said that he needed a generic set for different concrete types, so he'd have to write a bunch of these functions for all the combinations he needed. And he did. And it was a mess. And it was also slow.

Edit: not that we can conclude anything from the lack of performance, though, we don't know how it was written.

I believe it was a mess. But i don't believe it couldn't be done correctly in Go or whatever language you take.

My guess would be too much "noun oriented thinking".

Some of us came of age before the tyranny of King Java, learning such obsolescent tools as Pascal, Lisp and C back in school. (I'm gonna ignore BASIC and FORTRAN, other than as examples of what not to do) We learned how to pass around individual functions/procedures to support library code.

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

No, the problem is that SetUnion needs to be implemented six times for six different data types.

Well, as we all know, Go does give you a way, sort of. You'd have to write basically a dynamic version using interface {}, and then write wrappers casting the values in and out, and possibly handing out the equality predicate.

That sucked in Java at the time, though, when you had to screw around casting Objects in your code, I don't see why people would prefer that.

Surprisingly, Erik Meijer (Haskell, C#) can somewhat see the appeal of no generics and a bit of casting:

22m-31m http://www.youtube.com/watch?v=on5DeUyWDqI#t=22m

(I give myself and Google a pat on the back for being able to remember and quickly find this!)

Thanks.

For the app being described, would there really be six different type signatures required?

Generics would absolutely be nice for Go, primarily because they would allow the core libraries to provide all of these rich collections. However if we're discussing the notion that someone can write these themselves, it just seems contrived that people think generics are critical for any specific app -- in the example he described, it sounds like he would need one single concrete implementation.

No, only that in Go it's impossible to abstract the code that implements the "set union" functionality into a function.

I'm going to disagree:

    new_set = old_set.union( another_set, element_comparator_func);

If you allow some helper functions or an interface to do things such as compare/hash members, it's totally doable. Extra points for passing the helper(s) into the constructor.

Yes, you can still mismatch set types, but the casting/type-assertion in the helpers will fail with an explicit reason.

Almost forgot: in Go, classes aren't "closed". While you cannot "monkey patch" and change existing methods, you can define new functions, such as my_set_comparator, that accept each given type as "this". You would then make a new interface, such as my_set_element, which defines method my_set_comparator, and any data types for which you had defined my_set_comparator would automagically meet the new interface.

What's wrong with having them in the standard library?