[erlang-questions] OOP in Erlang

[Ulf Wiger]

Jesper Louis Andersen wrote:
> On Wed, Aug 11, 2010 at 10:37 AM, Hynek Vychodil <hynek@REDACTED> wrote:
>> On Wed, Aug 11, 2010 at 9:44 AM, Guy Wiener <wiener.guy@REDACTED> wrote:
>>> I have to stand up for OOP at this point: OOP does not start and end with
>>> "encapsulating code and data". The OOP feature that has the strongest impact
>>> on code brevity is *inheritance*. Thus, the interest in extending modules.
>> I can't agree with you.
> 
> Me neither. To provoke: Inheritance (In Java/C++ style OO) has a
> strong impact, but it is negative rather than positive. In my
> experience, all languages with no inheritance features whatsoever beat
> those with in brevity. In Erlang, whenever somebody thinks
> inheritance, you should take a step back and think "closure" or
> "higher order function". The whole concept of "Red car inherits from
> car" does not work, save for introductory Java courses. So in
> practice, inheritance is used to facilitate code reuse and composition
> - and in my experience, functional programming tend to have much
> better tools for composing code[1].

It's certainly useful to have the slightly abstracted discussion:
What types of programs are a breeze to write in language X, but
cumbersome in Erlang? What parts of Erlang make it cumbersome?
Could they be fixed? Do we care enough to fix it?

There are certainly problems that are not solved as easily in Erlang
as in other languages. Backtracking a bit, we can observe that one
of the first areas where Erlang departed from its main inspiration,
Prolog, was ...uhm, backtracking. This was not done because
backtracking is bad per se, but because it doesn't play that well
with soft real-time characteristics and hardware control.

Similarly there have been discussions on other features that are
much liked by proponents of Language X, but not found in Erlang:

- Strong static (a la Haskell & ML) typing is praised by many
   as a great boon to software quality and productivity.
   Explaining why Erlang doesn't have it sometimes borders on
   revisionism, but when defending his PhD thesis, Joe was asked
   about it and basically said that at the time, they didn't know
   that much about static typing, and were mainly inspired by
   dynamically typed languages like LISP and Prolog. In other words,
   it wasn't so much a question of deciding *against* static typing
   as getting inspiration elsewhere. Still, managing large projects
   with loosely coupled components that need to be upgradable in
   service is not an easy problem to solve, and largely still a
   research area.

- Lazy evaluation is superb for some problems, and e.g. QuickCheck
   relies heavily on it. While it can be done in Erlang, you have
   to make do with "poor-man's lazy evaluation", rolling your own.
   Again, going all the way seems to be somewhat at odds with soft
   real-time characteristics and predictable memory utilization.

- Shared-memory concurrency is the cat's miau for some problems,
   but Erlang carefully stays away from it, since it was designed
   for problems where shared memory is more trouble than it's
   worth - not least because all bets are off in terms of fault
   tolerance if a process with write access to your memory dies
   in the process of modifying it.

Finally, OO was on the plate even during the language experiments
that led to Erlang. It received favourable mention, but the old
papers (the ones I've read) don't clearly describe why OO features
were left out. I believe the main reason was that the team decided
to use Prolog as a base - as it was closest to what they imagined.
It was only later that they decided to make a language in its own
right.

My own experience from telecoms tells me that OO gives the wrong
signals to people in complex projects. They tend to want to
maximize design-time dependencies rather than going with a style
more similar to electrical component design - black boxes, with
well-defined interfaces. While expert OO programmers tend to
violently disagree with me, my opinion is based more on what
mere mortals tend to do with OO than on what the experts do.
I've seen too many occasions where C++ hackers have come up
with a great-looking prototype, offering superb performance
and seemingly ultra-compact code, although carefully ignoring
many of the harder problems and exception flows. The problem is
that the prototype is then handed off to "normal" programmers,
who have to address all the trickiness that the prototype
didn't cover, and that's when it tends to go south...

In short, I have not missed OO when using Erlang in its original
domain. I have, on occasion, missed being able to conveniently
extend modules and override individual functions when working
on other things (e.g. like extending mnesia). OTOH, I've also
dug into some Ruby-on-Rails code to see if I could extend some
Redmine plugins, and that experience only strengthened my
opinion that you can go horribly wrong with OO and method
overriding - especially when there can be many modules overriding
the same function, and it's not especially clear in which order
they are processed[1].

The hardest part of designing a language is probably not what to
include, but what to leave out. Erlang is not a multi-paradigm
language[2], and shouldn't strive to become one IMHO.

BR,
Ulf W

[1] Actually it is clearly defined, but it took some time for me
to find it. RoR defines one order, and Redmine modifies it.
Maybe it's an acquired taste, but I must say I didn't immediately
take to it.

[2] There are such languages; e.g. Oz, Scala and perhaps LISP
(although LISP probably deserves a classification of its own).

-- 
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
http://www.erlang-solutions.com