Hey Michael, thank you for the extensive feedback. I am definitely going to check the link citating Alan Kay and get back to you.
I agree I mainly compare to Java/PHP and C++ because that's the languages majority of developers are coming from when starting with Go and they bring with them the techniques that worked in such a languages.
For now, my main argument is, I left out a lot of things like inheritance, polymorphism etc because they are extensions of Objects but the main purpose of an Object is to represent state. Objects expose their API for communication but they mainly maintain the state.
Go seems to work better stateless imo. and the language is optimised for communication, impulses, clear input/output and such design differs greatly comparing to the way we are used to design, encapsulate Objects.
I don't see how Objects behaviour and assosicated techniques would be beneficial in Go world. I am not saying it can't be done, it can, but it doesn't fit.
I will update the article in the afternoon with your feedback (let me know if you would like to add something more) as well will point out clearly why I compare mainly to Java/C++.
UPDATE:
Actually from the source you provided, Dr. Alan Kay stated:
"OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things."
communication is obvious
protection and hiding of state-process (encapsulation), and this was my main point. That's what Objects were mainly designed to do, which Structs were not. Therefore I don't consider Go as primarily OO language
I feel like OOP is more of a pattern/paradigm than a constraint. Some languages have constrained themselves to that single pattern but many (probably Go falls in this category) can be used as OOP, even if they are not constrained to it by design.
An example: the basics of OOP in Python and Ruby are implemented in the C layer. Is C a OOP language? Not really, but you can still use it that way.
Sure, fair point and it surely is not black/white binary answer. That's why the official Go doc states: "kind of". The question is, should you? ;) The only way to use Go as OO language is by abusing pointers for everything and that doesn't make too much sense to me.
Hey Michael, thank you for the extensive feedback. I am definitely going to check the link citating Alan Kay and get back to you.
I agree I mainly compare to Java/PHP and C++ because that's the languages majority of developers are coming from when starting with Go and they bring with them the techniques that worked in such a languages.
For now, my main argument is, I left out a lot of things like inheritance, polymorphism etc because they are extensions of Objects but the main purpose of an Object is to represent state. Objects expose their API for communication but they mainly maintain the state.
Go seems to work better stateless imo. and the language is optimised for communication, impulses, clear input/output and such design differs greatly comparing to the way we are used to design, encapsulate Objects.
I don't see how Objects behaviour and assosicated techniques would be beneficial in Go world. I am not saying it can't be done, it can, but it doesn't fit.
I will update the article in the afternoon with your feedback (let me know if you would like to add something more) as well will point out clearly why I compare mainly to Java/C++.
UPDATE:
Actually from the source you provided, Dr. Alan Kay stated:
"OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things."
I feel like OOP is more of a pattern/paradigm than a constraint. Some languages have constrained themselves to that single pattern but many (probably Go falls in this category) can be used as OOP, even if they are not constrained to it by design.
An example: the basics of OOP in Python and Ruby are implemented in the C layer. Is C a OOP language? Not really, but you can still use it that way.
Sure, fair point and it surely is not black/white binary answer. That's why the official Go doc states: "kind of". The question is, should you? ;) The only way to use Go as OO language is by abusing pointers for everything and that doesn't make too much sense to me.
ahhaha "should you" is another relative question :D
unfortunately :D damn IT.