If you want data abstraction to do at least a minimum of static invariant enforcement, you pretty much have to use abstract data types. But if you're fine with littering logs with “exception was caught here, such and such data structure was corrupted”, suit yourself.

It isn’t that. Abstract data types are designed specifically for data structures like queues and stacks, they don’t make much sense for objects that don’t have such well defined invariants. No major language has adopted them for that reason.

> Abstract data types are designed specifically for data structures like queues and stacks

Guess what all nontrivial programs manipulate in the end.

> objects that don’t have such well defined invariants

... are either stateless or useless. It is impossible to define useful algorithms that manipulate objects of which you cannot say anything.

> No major language has adopted them for that reason.

The real reason is “programmers cannot reason about invariants anyway”.

Abstract data types are pretty good if the concrete types are machine generated.

Are you looking for the canonical encoding of ADTs in Scala?

I believe grand parent is referring to abstract data types, not algebraic data types. They are often confused because they share the same acronym.

the sort.Interface is an abstract data type. It's poorly named IMO. If it's called sort.Collection, it'd make more sense

A Go interface type is not an abstract data type. The difference is not even subtle:

(0) An ADT has a single internal representation that is known to the implementor, but hidden from users. The upside is that the ADT implementor can use his knowledge of the representation to optimize on n-ary operations, i.e., operations that act on several instances of the ADT. The downside is that ADTs cannot be extended by third parties. You would have to create a different ADT, even if satisfies the same contract.

(1) A Go interface has a list of methods, but does not proscribe any fixed internal representation. The upside is that anyone can create values of an interface type as long as they can implement the methods. The downside is that it is difficult to implement n-ary operations, because, at any point in the program, the implementor only knows the internal representation of the single value they are currently creating.

In other words, ADTs optimize for efficiency and predictability, whereas interfaces optimize for flexibility and extensibility. As a general rule, ADTs require more time than interfaces to plan ahead their design and implementation, but already implemented ADTs are easier to use correctly than already implemented interfaces.

I haven't dealt with Java in the last ... 12 years (and only very little back then), but I liked the convention of naming Interfaces after adjectives. In Java, it would be named Sortable, and element types of a sortable collection would implement Comparable<T>.