[TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
jonathan.aldrich at cs.cmu.edu
Fri Apr 19 14:30:27 EDT 2013
>> A critical property of objects, which is used architecturally in many OO systems, is support for heterogeneous data structures: e.g. putting several different implementations of an abstraction into a list. You can do this is Haskell only through a "slightly clumsy" encoding that wraps a type class in another data structure, thereby existentially quantifying over the type class used. See "Simulating objects" near the end of Simon Peyton Jones's talk:
> I don't see this as clumsy at all. Rather, it's clumsy to abstract over operations that are uniform in most OO languages because they insist on conflating mechanisms that should be orthogonal. Haskell has a more proper separation of concerns.
Well, some things that are easy to express in Haskell are awkward in OO
languages, and some things that are easy to express in OO languages are
awkward to express in Haskell. I think most neutral observers would
agree that adding gratuitous wrap/unwrap operations whenever you want to
access an object stored in a list is at least "slightly clumsy" (Simon's
words, not mine).
This matters in practice. If a language makes use of an idiom awkward,
developers will use it only rarely, and that affects the design of
software. If the requirements of a software system require using an
idiom over and over again, and that idiom is awkward to express in a
particular language, that language is in practice unsuitable for use in
building that software system.
It's my opinion (and I am in the process of gathering evidence for it)
that this can explain a lot of the success of OO languages. Lots of
systems in practice can't be built effectively without objects (e.g. to
store heterogeneous implementations of an abstraction in a list), and
those abstractions are too awkward to encode over and over again without
built-in language support.
The solution is not to complain about how weak objects are in comparison
to one's preferred form of abstraction; it is rather to develop
languages in which both forms of abstraction are well-supported (in
practice, not just in theory).
More information about the Types-list