public Node(SortedSet<T> left, T element, SortedSet<T> right) {
this.left = left ;
this.right = right ;
this.element = element ;
Isn't really mathematics. Nodes have a label. Any record attached to the node is business logic. It doesn't matter if the tuple is (first, last, address, department) or (value left, right), these are not part of the mathematics. Sure (value, left, right) looks like math, but it's just a convenient place to cache the edges describing a particular form of graph.
A graph is defined mathematically G = {V, E}. A single vertex with no edges is a graph. A set of vertices with no edges is also a graph. These may or may not be interesting, but edges are dependent on vertices. The converse is not true.
This example with Node(value, left, right) is standard object oriented fair. It's worse than Car(model, manufacturer, color, year). The Car simplifies something complex. Node(value, left, right) makes something simple more complicated. It's an implementation not an abstraction.
The article seems to be not-so-subtly hinting that Java is an anti-math programming language, and I agree. The language encourages each developer to reinvent and reimplement key concepts in terms of "classes" that are much more succinctly described in languages that embrace abstract algebra. The example of using inheritance and dynamic dispatch to represent a union type, is a perfect example.
Union types is not a key concept in abstract algebra, I bet that most mathematicians have never even heard of it. I'd like to hear about its use in abstract algebra, how would you define the union type of the simplest of simple objects without breaking its operation: a group with a group?
The concept is called a coproduct. The coproduct of two sets is the disjoint union. The coproduct of two abelian groups is also called the direct sum [edited], and the category of general groups does not have coproducts. The coproduct of two types in the category of types is exactly the union type. The idea of an Abelian category (basically, a "nice" category) requires the existence of coproducts, which I think is widely used enough in universal algebra to be considered a key concept.
I wrote a long (and unfinished) series about how to interpret category theory with programs on my blog [0], and in [1] I cover universal properties and the coproduct, which describes how you would formulate a "union type" in any category.
I didn't say that union types are a key concept in abstract algebra, and I'm not a mathematician by any means, although I vaguely understand that a disjoint union is a thing in set theory.
What I'm saying is that languages that do embrace concepts from abstract algebra, are much more expressive than languages that eschew these concepts (like Java).
No, groupoids breaks the group operation and thus behaves like neither of the groups. Do type systems allow operations between union types? If not then it is just a simple interface in OO. If they do then you are no longer working with pure functions.
A graph is defined mathematically G = {V, E}. A single vertex with no edges is a graph. A set of vertices with no edges is also a graph. These may or may not be interesting, but edges are dependent on vertices. The converse is not true.
This example with Node(value, left, right) is standard object oriented fair. It's worse than Car(model, manufacturer, color, year). The Car simplifies something complex. Node(value, left, right) makes something simple more complicated. It's an implementation not an abstraction.