> And the namespace is completely riddled with bugs. union returns duplicates if some of the inputs are lists instead of sets depending on their length.
to be clear I assume he is taking about this:
```
try-spec.core=> (clojure.set/union [1,2] [1,2])
[1 2 1 2]
```
Though im not sure what "depending on their length means".
> for the above bugs there are two possible fixes: raise an IllegalArgumentException if anything other than sets are provided
Isn't this an argument for types? Wont this type of problem be prolific in any dynamic language? What is the union of anything besides sets?
> coerce lists and vectors to sets before continuing
This only works for very similar data. How do you coerce a map into a set? Is it based on keys or values? What about a string? is it based on the whole string or the characters. I loaded up python3 to see how it was handled...
```
In [7]: set(["hello"]).union(["hello"])
Out[7]: {'hello'}```
is that what you would expect? Maybe. But honestly it should have thrown an error imo. Python is just skirting the issue. A set needs a hashable type. A list isn't one because its mutable. So python knew you "meant" a set of the items in the list... It throws up its hands if you force the issue further:
```
In [8]: x = [1,2,3]
In [9]: set(x)
Out[9]: {1, 2, 3}
In [10]: set([x])
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
in ()
----> 1 set([x])
TypeError: unhashable type: 'list'```
The problem is that we have handed the union function the wrong type of arguments. That it fails in further down stream is the trade off we make with dynamic languages. The community seems to admit the trade off and alleviate it with things like clojure.spec. Im not mental equipped to argue type theory here. But i suppose i feel this is an _ancient_ argument and saying its a "bug" seems simplistic.
> How you define getting the wrong type with nonsense values counts as “working” is beyond me. Is it just because it doesn’t throw an Exception? Anyone here prefer bad data instead of exceptions when dealing with functions like this? I doubt it.
This is maybe the deeper problem. You would expect union to fail given the wrong types. Sure the failure wont be a type error but it will be contained inside the function. Leaking out the wrong data means its harder to debug. I'm generally curious how and why set would work on lists at all.
As to the rest of the arguments made here. I don't know enough to hazard a guess. But i would appreciate any feedback on my interoperation of the above situation.