[TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages

[Jonathan Aldrich]

>> 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).

Jonathan