Re:Joe Armstrong About Erlang (interview)
by fogus on Monday November 29, 2010 @10:12AM
(#1950494)
Classic quote:
You've been reading my OOP sucks blogs. I saw a blog yesterday, they said Erlang is actually more object oriented, truer to the spirit of pure object orientation than all object oriented languages. You could take two views: you could say either Erlang isn't object oriented - which I used to say a few years ago - or you could say it's more object oriented than all the object oriented languages.
Re:Joe Armstrong About Erlang (interview)
by davidw on Monday November 29, 2010 @11:06AM
(#1950701)
Which is a bit glib though; because, especially if you've got something like OTP, you do a variety of things "underneath" that have nothing to do with sending messages back and forth.
Re:Joe Armstrong About Erlang (interview)
by masklinn on Monday November 29, 2010 @01:04PM
(#1951131)
And most OO languages devolve to imperative masses within methods. You could see Erlang as an OO/functional language (similar to OCaml, except asynchronous and dynamically typed) whereas C++, Java or Python are OO/imperative.
Re:Joe Armstrong About Erlang (interview)
by davidw on Monday November 29, 2010 @03:09PM
(#1951605)
If you really wanted to see it that way, I think something like Reia might be a more interesting way of capturing it, myself. OTP has too much boilerplate for my tastes.
Re:Joe Armstrong About Erlang (interview)
by jeff95350 on Monday November 29, 2010 @12:53PM
(#1951099)
"[in OO programming] I also have what you would call the categorization problem: which object do I put my code in?"
It seems to me like object-oriented style forces hierarchies onto the problem. It's fine to use hierarchies when it is a part of the problem, but when it's not, it causes all kinds of problems.
Re:Joe Armstrong About Erlang (interview)
by masklinn on Monday November 29, 2010 @01:14PM
(#1951163)
> Erlang doesn't seem to impose hierarchies at all.
True and not true, if you see Erlang as an object oriented language you still have three hierarchies at least:
1. for a given behavior, should it be packaged as a process or as a function? And if it's a function, in which module does it live? Granted, erlang's modules are "flat" so you don't get much of a hierarchy here.
2. Processes are organized in trees, because to send a message to a process you need a reference to it (its pid). Processes can be opted out of a tree by registering it globally, but that's about it. You could argue it's more of a bush as processes can communicate in a ring or with one another.
3. Supervision trees are most definitely hierarchies.
You've been reading my OOP sucks blogs. I saw a blog yesterday, they said Erlang is actually more object oriented, truer to the spirit of pure object orientation than all object oriented languages. You could take two views: you could say either Erlang isn't object oriented - which I used to say a few years ago - or you could say it's more object oriented than all the object oriented languages.
It seems to me like object-oriented style forces hierarchies onto the problem. It's fine to use hierarchies when it is a part of the problem, but when it's not, it causes all kinds of problems.
Erlang doesn't seem to impose hierarchies at all.
True and not true, if you see Erlang as an object oriented language you still have three hierarchies at least:
1. for a given behavior, should it be packaged as a process or as a function? And if it's a function, in which module does it live? Granted, erlang's modules are "flat" so you don't get much of a hierarchy here.
2. Processes are organized in trees, because to send a message to a process you need a reference to it (its pid). Processes can be opted out of a tree by registering it globally, but that's about it. You could argue it's more of a bush as processes can communicate in a ring or with one another.
3. Supervision trees are most definitely hierarchies.