5 ms·

> Most interfaces have one implementation. Instead, they are about abstraction, design, and so on. Then what you want is an abstract data type. Unlike interfac

> Most interfaces have one implementation. Instead, they are about abstraction, design, and so on. Then what you want is an abstract data type. Unlike interfaces, which can be implemented anywhere, an abstract data type is implemented in a single place. This has obvious benefits for performance (clients don't need to dynamically dispatch on operations), control (implementors don't need to worry about malicious clients supplying impostors) and precision (a single module can export several abstract types, whose implementations are mutually dependent). Go's interfaces are pretty terrible at all of the above. Not that Java provides anything substantially better.

kuschku 9y ago
Luckily, Kotlin does provide much better ADTs, and Java can be swapped out for Kotlin 1:1. While Go is reinventing the languages of the 80s in the 2010s.
- catnaroek 9y ago
  Abstract data types have nothing to do with either algebraic data types or abstract classes.
seanmcdirmid 9y ago
I have only seen abstract data types used to describe stacks and queues, and never in the context of a larger design where the underlying implementations weren’t data structures but objects. Do you have any good examples?
- deleted 9y ago
  [deleted]
- catnaroek 9y ago
  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.
  - seanmcdirmid 9y ago
    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.
    - landryraccoon 9y ago
      Abstract data types are pretty good if the concrete types are machine generated.
    - catnaroek 9y ago
      > 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”.
- still_grokking 9y ago
  Are you looking for the canonical encoding of ADTs in Scala?
  - seanmcdirmid 9y ago
    I believe grand parent is referring to abstract data types, not algebraic data types. They are often confused because they share the same acronym.
- chewxy 9y ago
  the sort.Interface is an abstract data type. It's poorly named IMO. If it's called sort.Collection, it'd make more sense
  - krylon 9y ago
    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>.
  - catnaroek 9y ago
    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.

kuschku 9y ago

Luckily, Kotlin does provide much better ADTs, and Java can be swapped out for Kotlin 1:1. While Go is reinventing the languages of the 80s in the 2010s.

catnaroek 9y ago
Abstract data types have nothing to do with either algebraic data types or abstract classes.

seanmcdirmid 9y ago

I have only seen abstract data types used to describe stacks and queues, and never in the context of a larger design where the underlying implementations weren’t data structures but objects. Do you have any good examples?

deleted 9y ago
[deleted]
catnaroek 9y ago
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.
- seanmcdirmid 9y ago
  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.
  - landryraccoon 9y ago
    Abstract data types are pretty good if the concrete types are machine generated.
  - catnaroek 9y ago
    > 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”.
still_grokking 9y ago
Are you looking for the canonical encoding of ADTs in Scala?
- seanmcdirmid 9y ago
  I believe grand parent is referring to abstract data types, not algebraic data types. They are often confused because they share the same acronym.
chewxy 9y ago
the sort.Interface is an abstract data type. It's poorly named IMO. If it's called sort.Collection, it'd make more sense
- krylon 9y ago
  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>.
- catnaroek 9y ago
  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.