Objective-C Lessons from Go(mackross.net)
mackross.net
Objective-C Lessons from Go
http://mackross.net/objc/2013/07/23/objective-c-lessons-from-go/
2 comments
> Go is procedural and Objective-C is object-oriented
Go is as 'object oriented' as any other modern language. It is just a different version of object-orientation than the norm, namely: it has no type (or object) hierarchy and types instead of classes. Not that the 'norm' here is object oriented either, at least ont by the definition of OOP's inventor.
http://golang.org/doc/faq#Is_Go_an_object-oriented_language
An imperative language can be object oriented or not. C++ is an imperative language (and according to the inventor of the term 'object oriented' C++ was not his idea of the concept).
It is more usual to put functional & concatenative languages on the other side of the coin to imperative languages. Whether a program could be read as a list of as a tree was once seen as fundamentally different. Now we realise that being concurrent is just as important, if not more so. Go is a concurrent language.
These labels are, admittedly, all grey and fuzzy. Alan Kay was thinking of Lisp when he first coined the term OOP.
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
It is the Message passing in Objective C that makes it closer to the original definition of 'Object Oriented' not the Type Hierarchy.
Whether Go is or isn't object oriented is an irrelevance. Goroutines and channels are what gives the language its elegance and power.
If you don't understand this you are fundamentally misunderstanding what Go is all about.
Go is as 'object oriented' as any other modern language. It is just a different version of object-orientation than the norm, namely: it has no type (or object) hierarchy and types instead of classes. Not that the 'norm' here is object oriented either, at least ont by the definition of OOP's inventor.
http://golang.org/doc/faq#Is_Go_an_object-oriented_language
An imperative language can be object oriented or not. C++ is an imperative language (and according to the inventor of the term 'object oriented' C++ was not his idea of the concept).
I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.
It is more usual to put functional & concatenative languages on the other side of the coin to imperative languages. Whether a program could be read as a list of as a tree was once seen as fundamentally different. Now we realise that being concurrent is just as important, if not more so. Go is a concurrent language.
These labels are, admittedly, all grey and fuzzy. Alan Kay was thinking of Lisp when he first coined the term OOP.
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
It is the Message passing in Objective C that makes it closer to the original definition of 'Object Oriented' not the Type Hierarchy.
OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.
Whether Go is or isn't object oriented is an irrelevance. Goroutines and channels are what gives the language its elegance and power.
If you don't understand this you are fundamentally misunderstanding what Go is all about.
Go is procedural and Objective-C is object-oriented
I'm not sure that Go is entirely procedural - types and type embedding mean it also has concept of tying data and functions which operate on that data together, controlling access etc.
The type system in Go fits nicely with some similar ideas in Objective C - Obj-C Protocols are similar to interfaces (though in Obj-C they are explicitly declared and adhered to, unlike Go), and Categories are similar to Type Embedding in Go (though there are differences of course). So those two ideas of duck-typing and composition work across both languages, though obviously there are differences in that Obj-C has a more traditional Object inheritance model as well.
I'm not sure that Go is entirely procedural - types and type embedding mean it also has concept of tying data and functions which operate on that data together, controlling access etc.
The type system in Go fits nicely with some similar ideas in Objective C - Obj-C Protocols are similar to interfaces (though in Obj-C they are explicitly declared and adhered to, unlike Go), and Categories are similar to Type Embedding in Go (though there are differences of course). So those two ideas of duck-typing and composition work across both languages, though obviously there are differences in that Obj-C has a more traditional Object inheritance model as well.
The two approaches are more similar than one might think: inheritance is a special case of composition. In fact, traits (in some languages called typeclasses) unify inheritance and composition quite nicely.
Actually, there is no need to think that would Go do. Compostion is strongly favoured in Obj-C and Cocoa (Touch) frameworks, and this is quite strongly stressed everywhere.
All well and good, but keep in mind there's a fair bit of boilerplate to this way of composing classes and you don't get any type checking when you use dynamic forwarding.
I enjoy using both languages (Objective-C by day, Go by night), but I'm not sure this advice is necessarily something I would follow.
Because at the root of it all, Go is procedural and Objective-C is object-oriented. But the word "procedural" (or "imperative") isn't mentioned once in this blog post...it seems as if maybe the author missed something here? For example:
>In Go, composition of existing classes is trivial
...classes simply don't exist in Go. Composition of interfaces, yes, not classes. And maybe that's me being picky, but I think it's a really important distinction. One of the reasons I think the author found taking this further "incredibly difficult" is that the two methodologies are very different and perhaps shouldn't mix.
Maybe other people will have differing views, but I honestly don't know whether it is worth trying to impose a procedural viewpoint onto a overtly object orientated language (or vice versa). So to throw this open: am I missing something here?