Objects Are Not Abstract Data Types | Hacker News Reader

Objects Are Not Abstract Data Types

stuartsierra.com

21 pointsbgray4 comments

"Object-oriented languages, Liskov said, tend to conflate the concrete representation of a type with the interface used to access it."

This is why I prefer C to C++. An opaque data type in C has a clean separation of the interface from the implementation. C++ classes tend to have both methods and implementation-dependent data specified in a single file. Granted, one can write good or bad code in any language, but I've found C encourages good behavior in this regard more than C++.

I really wish people could just abstain from using the built-in class abstractions in their C++, instead of switching wholesale to C and losing all of C++'s other niceties (templates, exceptions, less cruft on portability of primitives, etc.) C++-without-classes is a really nice medium-level language, one that's a lot better at being C than C is, and it'd be nice if more things could be written in it. It would be perfect for the Linux kernel and GNOME, for example.

However, as you've said, C++ encourages you to use its badly-thought-out class abstractions, and that's what most people who "code C++" tend to know how to do. Linus, I believe, disallowed C++ specifically because people would gradually write the kernel into a maintainability corner, by modeling things as hierarchies of classes without understanding the implications.

What are the similarities and differences between working with a CLU-type type/cluster separation for fields and methods, and a CLOS-style multi-method approach, which has methods and generics standing free from objects and classes? It seems like CLU follows a more traditional single-dispatch paradigm, with the fields and the methods in different layers but bundled together, while CLOS separates the methods not just from the fields but from everything. But I haven't worked with either, so I'm just guessing. Can anyone comment from experience?

I'm clueless about CLOS and just learning Clojure. Corrections solicited, grain of salt, yadda yadda:

1. Clojure already provides multimethods, which can dispatch CLOS-style, based on number/type of their arguments, or by an arbitrary predicate.

2. To use your wording, while CLOS separates methods from "everything", Clojure multimethods are even separated from classes. Other than being type-aware enough to do dispatch, multimethods are conceptually just functions with some extra testing on the front end.

3. Implementation-wise, things seem to be different. Perusing the links below, it seems the new functionality is intended to preserve dynamism/performance when Java and Clojure objects interact.

4. Grouping functions into logical chunks seems to be the other idea behind protocols.

Reply on news.ycombinator.com