7 ms·

If you want to really see OOP in action study Erlang. As the late great Joe Armstrong says in his introductory book, Erlang is a real OOP system - objects can o

If you want to really see OOP in action study Erlang. As the late great Joe Armstrong says in his introductory book, Erlang is a real OOP system - objects can only communicate through message passing. There is no notion of visibility, friendship, inheritance, etc. Objects can hold state and pass messages and that's it - which coincidentally makes concurrency dead simple. What most people think of when they think OOP is C++, Java, and Python which got OOP completely wrong and ruined our perception of OOP. They also tried to use their misshapen OOP hammer on every problem they could find to the point that it’s an overused meme. These days you see languages actively trying to distance themselves from OOP as a form of enticement (Rust and Go being the two prime examples).

fiddlerwoaroof 7y ago
In a dynamically-typed message-passing system, inheritance is just automatically delegating messages to another actor and possibly modifying the results. Erlang may not have explicit inheritance, but people almost certainly implement inheritance-like actor structures to achieve extensible message dispatch.
- zozbot234 7y ago
  > inheritance is just automatically delegating messages to another actor and possibly modifying the results. I don't think this is true. Objects can message themselves as part of base-class code; implementation inheritance means that this has to involve a level of indirection and dispatch, not just explicit delegation.
  - fiddlerwoaroof 7y ago
    This isn't always implicit, though: python's explicit self is still "object-oriented"
xscott 7y ago
> These days you see languages actively trying to distance themselves from OOP as a form of enticement (Rust and Go being the two prime examples). They definitely distance themselves from inheritance. However both Rust traits and Go interfaces look to me like they're there to appease people who like the .method() calling syntax. (I know there's more to the story than that, particularly for Rust and its type system...) I think either could've gone with multimethods or overloaded functions and have been better for it, but a lot of people seem to really like the object.method() look.
- cgrealy 7y ago
  > a lot of people seem to really like the object.method() look. There’s a pretty simple reason for that: autocomplete. In most halfway decent dev environments, typing “object.” will present you with a list of possible operations on that object. OTOH, if you want to do “method(object)” you need to know the method name (in all current scopes, including globals). I’m not saying this is the only or even best way to write code, but it’s definitely a factor IMHO.
  - xscott 7y ago
    You're almost certainly right, this is pretty compelling. It's not the way I work, but I'm sure lots of people really like their IDEs. Despite that, I recently changed one of my APIs from being: result foo(bar b, other stuff) result foo(baz b, other stuff) result foo(bum b, other stuff) To: result r = bar.foo(other stuff) result r = baz.foo(other stuff) result r = bum.foo(other stuff) Not because of the IDE, but because the compiler error messages are horrible for the ones above when you make a mistake. If you pass the type as the first argument, the compiler "helpfully" tells you 3 pages of information about all of the overloads. However, if you use method syntax, it only tells you overloads for the one object. It's a little frustrating that the hammer is changing the shape of our hands, and not vice versa.
    - jcelerier 7y ago
      > It's a little frustrating that the hammer is changing the shape of our hands, and not vice versa. the "hammer" in this case being "doing things in causal order" - hard to find a different tool in the shed.
      - xscott 7y ago
        I don't understand what you mean by "causal" in this context. A.f(B) is just a syntax sugar around f(A, B) unless dynamic dispatch comes into play. Then it's usually syntax sugar around something like: A._vtable[f](A, B) It really is just a function of two arguments, even when the privileged first argument looks like it's outside of the parens.
pjmlp 7y ago
Go and Rust OOP view of the world are also possible in C++, Java, Python, C#. It is a matter of actually learning about OOP concepts in general, and Kant features in particular. Swift's protocol oriented programming actually goes back to Objective-C protocols, Java's inspiration for interface types or Smalltalk traits (post-Smalltalk-80).
bernawil 7y ago
> completely wrong and ruined our perception of OOP. or maybe Erlang is its own thing and OOP -as what most people are thinking when talking about it- is the set of practices followed in languages descended from the cross between C and Smalltalk. This explains how every introductory course in OOP using either Java, C#, Python, etc. will list some sort of OOP principles always including something along "objects talk to each other though message passing" which is hand-waved simply as something to do with taking other objects by ref // taking a reference bar.someMethod(foo) Or some form of import method import Foo; class Bar { someMethod() { // init the import foo = new Foo() // ... do something with it foo.someMethod() } } which is worse since you need a huge disclaimer to explain that in practice you need to account for Dependency Injection and something for Mocking.

fiddlerwoaroof 7y ago

In a dynamically-typed message-passing system, inheritance is just automatically delegating messages to another actor and possibly modifying the results. Erlang may not have explicit inheritance, but people almost certainly implement inheritance-like actor structures to achieve extensible message dispatch.

zozbot234 7y ago
> inheritance is just automatically delegating messages to another actor and possibly modifying the results. I don't think this is true. Objects can message themselves as part of base-class code; implementation inheritance means that this has to involve a level of indirection and dispatch, not just explicit delegation.
- fiddlerwoaroof 7y ago
  This isn't always implicit, though: python's explicit self is still "object-oriented"

xscott 7y ago

> These days you see languages actively trying to distance themselves from OOP as a form of enticement (Rust and Go being the two prime examples). They definitely distance themselves from inheritance. However both Rust traits and Go interfaces look to me like they're there to appease people who like the .method() calling syntax. (I know there's more to the story than that, particularly for Rust and its type system...) I think either could've gone with multimethods or overloaded functions and have been better for it, but a lot of people seem to really like the object.method() look.

cgrealy 7y ago
> a lot of people seem to really like the object.method() look. There’s a pretty simple reason for that: autocomplete. In most halfway decent dev environments, typing “object.” will present you with a list of possible operations on that object. OTOH, if you want to do “method(object)” you need to know the method name (in all current scopes, including globals). I’m not saying this is the only or even best way to write code, but it’s definitely a factor IMHO.
- xscott 7y ago
  You're almost certainly right, this is pretty compelling. It's not the way I work, but I'm sure lots of people really like their IDEs. Despite that, I recently changed one of my APIs from being: result foo(bar b, other stuff) result foo(baz b, other stuff) result foo(bum b, other stuff) To: result r = bar.foo(other stuff) result r = baz.foo(other stuff) result r = bum.foo(other stuff) Not because of the IDE, but because the compiler error messages are horrible for the ones above when you make a mistake. If you pass the type as the first argument, the compiler "helpfully" tells you 3 pages of information about all of the overloads. However, if you use method syntax, it only tells you overloads for the one object. It's a little frustrating that the hammer is changing the shape of our hands, and not vice versa.
  - jcelerier 7y ago
    > It's a little frustrating that the hammer is changing the shape of our hands, and not vice versa. the "hammer" in this case being "doing things in causal order" - hard to find a different tool in the shed.
    - xscott 7y ago
      I don't understand what you mean by "causal" in this context. A.f(B) is just a syntax sugar around f(A, B) unless dynamic dispatch comes into play. Then it's usually syntax sugar around something like: A._vtable[f](A, B) It really is just a function of two arguments, even when the privileged first argument looks like it's outside of the parens.

pjmlp 7y ago

Go and Rust OOP view of the world are also possible in C++, Java, Python, C#. It is a matter of actually learning about OOP concepts in general, and Kant features in particular. Swift's protocol oriented programming actually goes back to Objective-C protocols, Java's inspiration for interface types or Smalltalk traits (post-Smalltalk-80).

bernawil 7y ago

> completely wrong and ruined our perception of OOP. or maybe Erlang is its own thing and OOP -as what most people are thinking when talking about it- is the set of practices followed in languages descended from the cross between C and Smalltalk. This explains how every introductory course in OOP using either Java, C#, Python, etc. will list some sort of OOP principles always including something along "objects talk to each other though message passing" which is hand-waved simply as something to do with taking other objects by ref // taking a reference bar.someMethod(foo) Or some form of import method import Foo; class Bar { someMethod() { // init the import foo = new Foo() // ... do something with it foo.someMethod() } } which is worse since you need a huge disclaimer to explain that in practice you need to account for Dependency Injection and something for Mocking.