

Objective-C Lessons from Go - mackross
http://mackross.net/objc/2013/07/23/objective-c-lessons-from-go/

======
objclxt
> _So, the next time you’re about to make a subclass. Think hard and ask
> yourself — what would Go do._

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?

~~~
sambeau
_> 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](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.
    

[http://en.wikiquote.org/wiki/Alan_Kay](http://en.wikiquote.org/wiki/Alan_Kay)

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...](http://userpage.fu-
berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)

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.
    

Go's real strength for modern server software writing is in it Concurrency. It
is this that makes it important and my first go-to language for anything
server-side, especially any problem requiring the simultaneous serving of
thousands of clients.

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.

------
tomlu
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.

