Is Erlang Object-Oriented?

Question

Message-passing is a fundamental part of Erlang. Alan Kay has argued that message-passing is a concept more important than objects in his view of object-oriented programming (and he "invented" the term!).

Can Erlang be considered an object-oriented programming language (à la Smalltalk)?

Answer 1

Would you call this code "object oriented" ?

main() ->

    Clock1 = clock:constructor() , 

    H1 = Clock1:getTime() ,

    timer:sleep( 1500 ) , 

    H2 = Clock1:getTime() ,

    Clock1:setTime( 100 ) , 

    timer:sleep( 1500 ) , 

    H3 = Clock1:getTime() ,

    Clock1:stop( ) 

        . % main ()

This the implementation of this "Erlang class" clock.

%% --------------------------------------------------------
%%
%% clock.erl
%%
%% --------------------------------------------------------

%% ------------------------------------------------
%% ------------------------------------------------
-module( clock ).
-export( [ constructor/1, constructor/0, loop/1, 
           getTime/1, setTime/2, stop/1,
           ticTac/1
         ] ). 

%% ------------------------------------------------
%% 
%% ------------------------------------------------
-record( clock, { time } ).

%% ------------------------------------------------
%% 
%% ------------------------------------------------
constructor() -> constructor( 0 ) . % ()

%% ------------------------------------------------
%% 
%% ------------------------------------------------
constructor(H) ->
    %%io:fwrite( "\nclock:constructor()\n" ) ,

    LoopPid = spawn( ?MODULE, loop, [ #clock{ time=H } ] ) ,

    TicTacPid = spawn( ?MODULE, ticTac, [ LoopPid ] ) ,

    {clock, LoopPid}
    . % ()

%% ------------------------------------------------
%% 
%% ------------------------------------------------
ticTac( LoopPid ) ->
    timer:sleep(1000) ,
    LoopPid ! ticTack ,
    ticTac( LoopPid ) 
        . % ()

%% ------------------------------------------------
%% 
%% ------------------------------------------------
loop( State ) ->

    %% io:fwrite( "\nclock:loop()\n" ) ,

    receive
        {Pid, get} -> Pid ! State#clock.time ,
                      loop( State )  ;

        {set, H} -> loop( #clock{ time=H } ) ; 

        stop -> ok ;

        %%after 1000 ->  % creo que se reinicia tras cada recepción
        ticTack ->
                io:fwrite( ".\n" ) ,
                loop( #clock{ time=State#clock.time+1 } )
        end 

        . % ()

%% ------------------------------------------------
%% helper
%% ------------------------------------------------
getTime( {clock, PidLoopClock} ) ->

    PidLoopClock ! {self(), get} ,
    receive
        Time -> Time
        end

    . % ()

%% ------------------------------------------------
%% helper
%% ------------------------------------------------
setTime( H, {clock, PidLoopClock} ) -> 

    PidLoopClock ! {set, H} 

    . % ()

%% ------------------------------------------------
%% helper
%% ------------------------------------------------
stop( {clock, PidLoopClock} ) -> 

    PidLoopClock ! stop

    . % ()

%% --------------------------------------------------------
%% --------------------------------------------------------
%% --------------------------------------------------------
%% --------------------------------------------------------

Answer 2

There’s a great quote by Joe Armstrong, the creator of Erlang:

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

Answer 3

Joe Armstrong has published a post in his blog about OO and answered this question.

As Erlang became popular we were often asked "Is Erlang OO" - well, of course the true answer was "No of course not" - but we didn't to say this out loud - so we invented a serious of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully).

By the way, the article is a very interesting critic to OO: http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

Answer 4

By default it's not. But it can be.

Answer 5

Joe Armstrong has gone on record saying that he thinks that Erlang is "possibly the only object-oriented language" (the context adds "OO in the Alan Kay meaning of the word"). Johnson, in the same interview, points out the same things that Sean Copenhaver says in his answer: in the small, Erlang's a purely functional language; in the large, with processes, it looks exactly like Kay-style object orientation.

Answer 6

Quoting from Wikipedia which quotes from here:

Benjamin Cuire Pierce and some other researchers view as futile any attempt to distill OOP to a minimal set of features.

But looking at their own futile attempt:

• Dynamic dispatch - if you treat an Erlang process as an object, then yes, it's supported.
• Encapsulation - if you treat message sending / response as a method call, it's supported.
• Subtype polymorphism - kind of - if you stretch the definition of behaviours enough, it's supported
• object inheritance (or delegation) - without any correctness checking, you can substitute one object for another - so let's say it's ok
• Open recursion - it's supported (send to own process)

So yes - with some smoke and flashes, you could try claiming that Erlang is Object-Oriented. But I could use the same tricks to present C as an OO language, because you can use OO style in it and implement vtables manually.

An answer of any sane person looking at Erlang would likely be "no" Erlang is a functional / message passing oriented language.

Another answer could be "why bother classifying" / "who needs to know"?

Answer 7

I think that on the higher level Erlang is object-oriented given that you believe in the original concepts discussed around the term. By this I mean isolation, message passing, polymorphism.

Erlang's processes can hold on to state, perform actions on that state, and they are isolated from other processes since they can't directly effect each other. Since any process can receive any message (and a message can just as easily be delegated to another process who could send a reply to the original sender) I believe it also fulfills polymorphism.

Certainly Erlang on a lower level shows its functional aspects but again I think at the higher level (where you are passing and coordinating messages between processes) Erlang behaves in an object-oriented manner. You just can't get caught up thinking object-orientation is all about classes, inheritance, and method calling (which is different from message passing). That is only how the paradigm has been provided for us in most mainstream languages.