Very interesting and wide ranging discussion. Lots of ideas in there too:
> Joe Armstrong: What I’d like to see and we don’t do is integrate the language within the revision control system because if you rename a variable, and you submit it to the revision control system and say "This is a completely different version of a completely different program but you just rely on the variable because there is no semantics at all just to make it a little bit more readable if you correct a spelling mistake in a comment." The revision control system is a sort of generic and applied to any programming language and that’s really stupid. They need to be much more smart to check what really happening, not this superficial stuff.
> Don Syme: So we’ll have Erlang RCS, Erlang specialized?
Early on, Joe Armstrong talks about Erlang being "object oriented". I don't really agree though, because by the time you actually get processes and things put together - especially with OTP - you have a lot of other stuff running underneath, so you're not just operating at a 'pure' level of sending messages back and forth. And there's lots of boilerplate too. However, it's still a good way of thinking about Erlang from an architectural point of view.
I feel a bit for Martin as a non-native English speaker. It can be very easy for the native speakers to dominate a discussion unintentionally (and even when trying not to).
The impression Erlang gives me is one of being almost an anti-language, emphasising the system at large and discouraging over sophistication in the details. I think the point Joe Armstrong makes about hardware interoperability is telling. His vision of software is one much closer to hardware and the networking. Though I think the fact that there is an awful lot of unnecessary complexity in software it does not mean that sophistication and complexity is not sometimes necessary. Not that he ever voiced that, just sometimes in the process of advocating something pluralism can get left out.
I am amazed that there would still be discussions about what OOP is or is not.
The only agreement seems to be around "polymorphing" -- the ability to define a behaviour that works consistently over many "things" that share some similarities. Good.
But the root of evil comes back to very initial definition of what an object is:
An "object" is something very concrete, it is not a mere "thing", it has:
- an identity
- a state
- a behaviour
Is a "hello" an object? No, no more than 9 or any number is an object, because these beasts are "values".
However, the way a string is implemented is probably an object at some level (this is not true of a number, CPUs can deal with them directly). But this is an implementation detail.
Unfortunately the essential difference between what is a Value and what is an Object is poorly promoted/teached. But this is improving thanks to functional languages.
In a perfect world there would be "things", that are either "values" or "objects". In the imperfect world of us we have "objects", that are more or less mutable.
> An "object" is something very concrete, it is not a mere "thing", it has: - an identity - a state - a behaviour. Is a "hello" an object? No, no more than 9 or any number is an object, because these beasts are "values".
This seems to be strongly debated (still). Languages like Ruby (and Smalltalk) treat numbers as objects. You can argue that numbers are really objects with immutable state for example.
This is not to say that I disagree with what you are saying. But the topic itself is still debated (as is a lot of stuff about the theory and basics of object systems)
For sure, it is thing.
And for sure it is an object too.
What is "the plan to build a table"
For sure it is something, hence it is a thing.
But is it an object?
Well, if the plan is printed on a piece of paper, then for sure it is an object.
OTOH, if the plan for the table is in the head of some designer, then it is not an object, it's... an idea.
So basically, you have two planes (at least), the "physical plane", where object lie, very tangible, very concreate, and the "idea plane" where ideas lie, very abstract.
So, is 9 an object or and idea?
In CS, things that lie in the "idea plan" are called "values". That's probably because we don't hold it (yet) that computers can have ideas ;)
In most OOP scenarios one would model an application domain concept as a class, but then you get bogged down in implementing all sorts of minutiae that really have nothing to do in describing the model (e.g. getters/setters, initialization, etc.)
Clojure, for one, encourages the distinction between data structures that represent the programming domain, and data structures that represent the application domain.
There's defrecord, which goes a little further than record structures in other languages, in that it also gives the benefit of type-driven polymorphism.
Classes aren't necessary* for OO. Inheritance isn't necessary, either (and probably causes as many problems as it fixes).
Late-binding via message-passing pretty much covers it, IMHO. Structure code as a group of autonomous actors communicating by passing messages according to agreed-upon protocols, and each (polymorphically) chooses how to react to them. Erlang implements that model with unusual clarity, IMHO.
Personally I think of object-oriented programming as meaning procedural data abstraction - in OOP, a data abstraction (object) is the operations that can be performed on it. This is in contrast to e.g. ML/Haskell algebraic types where a type is the set of values it can take. An object-oriented language is then a language designed to support this style of data abstraction, just as a (pure or impure) functional-oriented language is a language designed to support (where "support" is a superset of "enforce") a style of programming based on composition of pure functions.
There doesn't need to be a distinction between Objects and Values:
Object -> Object' -> Object'' -> Object''' -> ...
The real problem with some popular OO languages is the conflation of state and identity. There are OO languages that avoid this "Worse Is Better" design.
13 comments
[ 3.3 ms ] story [ 26.5 ms ] thread> Joe Armstrong: What I’d like to see and we don’t do is integrate the language within the revision control system because if you rename a variable, and you submit it to the revision control system and say "This is a completely different version of a completely different program but you just rely on the variable because there is no semantics at all just to make it a little bit more readable if you correct a spelling mistake in a comment." The revision control system is a sort of generic and applied to any programming language and that’s really stupid. They need to be much more smart to check what really happening, not this superficial stuff.
> Don Syme: So we’ll have Erlang RCS, Erlang specialized?
Early on, Joe Armstrong talks about Erlang being "object oriented". I don't really agree though, because by the time you actually get processes and things put together - especially with OTP - you have a lot of other stuff running underneath, so you're not just operating at a 'pure' level of sending messages back and forth. And there's lots of boilerplate too. However, it's still a good way of thinking about Erlang from an architectural point of view.
The impression Erlang gives me is one of being almost an anti-language, emphasising the system at large and discouraging over sophistication in the details. I think the point Joe Armstrong makes about hardware interoperability is telling. His vision of software is one much closer to hardware and the networking. Though I think the fact that there is an awful lot of unnecessary complexity in software it does not mean that sophistication and complexity is not sometimes necessary. Not that he ever voiced that, just sometimes in the process of advocating something pluralism can get left out.
The only agreement seems to be around "polymorphing" -- the ability to define a behaviour that works consistently over many "things" that share some similarities. Good.
But the root of evil comes back to very initial definition of what an object is:
An "object" is something very concrete, it is not a mere "thing", it has: - an identity - a state - a behaviour
Is a "hello" an object? No, no more than 9 or any number is an object, because these beasts are "values".
However, the way a string is implemented is probably an object at some level (this is not true of a number, CPUs can deal with them directly). But this is an implementation detail.
Unfortunately the essential difference between what is a Value and what is an Object is poorly promoted/teached. But this is improving thanks to functional languages.
In a perfect world there would be "things", that are either "values" or "objects". In the imperfect world of us we have "objects", that are more or less mutable.
This seems to be strongly debated (still). Languages like Ruby (and Smalltalk) treat numbers as objects. You can argue that numbers are really objects with immutable state for example.
This is not to say that I disagree with what you are saying. But the topic itself is still debated (as is a lot of stuff about the theory and basics of object systems)
What is a table.
For sure, it is thing. And for sure it is an object too.
What is "the plan to build a table" For sure it is something, hence it is a thing.
But is it an object?
Well, if the plan is printed on a piece of paper, then for sure it is an object. OTOH, if the plan for the table is in the head of some designer, then it is not an object, it's... an idea.
So basically, you have two planes (at least), the "physical plane", where object lie, very tangible, very concreate, and the "idea plane" where ideas lie, very abstract.
So, is 9 an object or and idea?
In CS, things that lie in the "idea plan" are called "values". That's probably because we don't hold it (yet) that computers can have ideas ;)
See also http://virteal.com/ObjectVersusValue
Clojure, for one, encourages the distinction between data structures that represent the programming domain, and data structures that represent the application domain.
There's defrecord, which goes a little further than record structures in other languages, in that it also gives the benefit of type-driven polymorphism.
Late-binding via message-passing pretty much covers it, IMHO. Structure code as a group of autonomous actors communicating by passing messages according to agreed-upon protocols, and each (polymorphically) chooses how to react to them. Erlang implements that model with unusual clarity, IMHO.
* Neither are prototypes.
I am influenced by this paper -> http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOP... (warning: PDF), which expresses more carefully and precisely what I in the above paragraph expressed sloppily.
Haskell and Clojure come to mind.