Why Go is not OOP

[Ghassan Karwchan]

I should ask this question to the language designers, but what do you think guys?

Go has some similarity with nodes/modular paradigm, more that what it has with OOP

Am I right?

And why ?

Is OOP not good?

[Ian Lance Taylor]

Unfortunately OOP is not a precisely defined term. It means different
things to different people. Any discussion on this point will be more
clear if you explain what you mean by OOP.

Ian

[Shawn Milochik]

Go is object-oriented. OOP != classes and inheritance. . This has been discussed many times, so just do a little Google searching and you can read all about it.

I'm not being rude -- it's just not worth typing it all out again. 

[Roberto Zanotto]

Depends what you mean with "OOP". Go is object oriented in the sense that you have objects with fields (structs), constructors and methods. It is not OO in the sense that it does not have classes/inheritance. Inheritance is bad, google it :D

[Ghassan Karwchan]

Interesting answer, and it opened my eyes.

Thanks

[Manlio Perillo]

Il giorno mercoledì 6 gennaio 2016 18:33:13 UTC+1, Ghassan Karwchan ha scritto:

I should ask this question to the language designers, but what do you think guys?

Do you know Alan Kay?

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

According to Alan Kay:

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things"

Go has messaging (methods), local retention and protection and hiding of state-process.

It does not have late-binding since it is a static language.

Another quote attributed to Alan Kay is:

"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind."

Regards  Manlio 

[Peter Mogensen]

On 2016-01-06 18:43, Roberto Zanotto wrote:
> Depends what you mean with "OOP". Go is object oriented in the sense
> that you have objects with fields (structs), constructors and methods.
> It is not OO in the sense that it does not have classes/inheritance.

But OOP is also polymorphism.

And Go has some quirks.

For instance... you can have polymorphism when calling a method on an
interface value, but if the receiving object cannot in that method call
another method through the same interface value - since it simply
doesn't know which interface it was called through.

You can work around that by setting method value attributes on objects.
But Go hasn't got real virtual dispatch of methods.

/Peter

[Wim Lewis]

On Jan 6, 2016, at 11:01 AM, Manlio Perillo <manlio....@gmail.com> wrote:
> Go has messaging (methods), local retention and protection and hiding of state-process.
> It does not have late-binding since it is a static language.

Method invocations in Go are late-bound — any time you use an interface, you're using late binding. I wouldn't say that Go has *extreme* late-binding a la Smalltalk, but it does have what is IMHO the essential quality for OOP: I can be given an object and invoke some operation on it, with the implementation of that operation being automatically determined by the runtime type of the object.

[ajstarks]

One person's view: John Cinnamond - Go is a great OO language:  https://www.youtube.com/watch?v=HqZQBmNVhBw

[Fino]

for many years, I still cannot understand what is "OOP"

BR-fino 

[Aryeh Hoffman]

Go can be written in an object oriented style, but then so can assembler.  I'd argue to attempt to do so is not idiomatic Go.  Go has some characteristics of other object oriented languages, but does merely possessing a characteristic make it one?

Applications (software applied to a problem) in Go, are typically not written as a group of collaborating encapsulated entities (objects) that themselves collaborate to solve the problem.

Which is the following statements are true for Go?

1. Procedural code gets information then makes decisions.
2. Object-oriented code tells objects to do things.

-- Aryeh

[Dave Cheney]

> Object-oriented code tells objects to do things.

This sounds like calling methods on interface values to me. 

[Manlio Perillo]

Il giorno giovedì 7 gennaio 2016 17:57:27 UTC+1, Aryeh Hoffman ha scritto:

> [...] 

Which is the following statements are true for Go?

1. Procedural code gets information then makes decisions.
2. Object-oriented code tells objects to do things.

What is an object for you?

In Go a function lives in a package. When you call a function you tell a package to do somethings with its global internal state.

When you call a method, you tell a value to do something with its local internal state.

Regards  Manlio

 

 

[Jesper Louis Andersen]

On Wed, Jan 6, 2016 at 5:48 PM, Ghassan Karwchan <ghassan....@gmail.com> wrote:

I should ask this question to the language designers, but what do you think guys?

Go has some similarity with nodes/modular paradigm, more that what it has with OOP

Consult "Rees on OO":

http://mumble.net/~jar/articles/oo.html

Go has 1, 3 (maybe, see below), and 7 (I believe)

It means different things to different people. Even the word polymorphism, of which you have different kinds of such. Go notably lacks the parametric variant (which is often implemented as "generics" in mainstream languages), but it does support a kind of ad-hoc polymorphism though interfaces since it allows the underlying type to vary. Yet again, this is not ad-hoc as in the sense of Java where you can decide which function to call based on the type signature.

OO is complicated. And so is a term like FP, which also varies a lot depending on who you are debating.

--

J.

[Rob Pike]

It gets close on 5 too, although universe-defined types cannot have methods for orthogonal reasons. (An int can't have methods, but type MyInt int and off you go, without boxing.) And interfaces satisfy 6, of course. Embedding is a weak form of 8. I don't quite understand what is meant by 9.

Interpretations will vary.

-rob

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aryeh Hoffman]

What is an object for you?

For me it's the wrong question to ask. It's not what an object is that matters, it is what is an object oriented solution to a problem? It is one without a procedural set of instructions orchestrating data and code - modular or not. It is instead independent entities that encapsulate their own behavior, characteristics and state, interacting with each other solely by telling each other to do things themselves.

In Go a function lives in a package. When you call a function you tell a package to do somethings with its global internal state.

When you call a method, you tell a value to do something with its local internal state.

Given your description and ignoring naming, how at its core is this different from C? Or Algol?

I think the real issue, is whether people take a structural or architectural viewpoint.  If you only take a structural viewpoint, and consider only things like encapsulation and mechanisms for reuse, most languages and approaches since the 1950's have characteristics of each other. After all modularity and the relationship between procedure and data have been at the heart of our efforts since then.

I evidently take an architectural approach.

-- Aryeh

[Jesper Louis Andersen]

On Thu, Jan 7, 2016 at 9:20 PM, Rob Pike <r...@golang.org> wrote:

I don't quite understand what is meant by 9.

It *probably* means that an object is a function (and closure) where it's first argument takes the method you are interested in:

http://play.golang.org/p/PUKfauf6Uv

it is a super contrived example and it misses the necessary error handling for fully handling this, but the idea is that any object follows the pattern there and the valid method set is limited. You can also implement open recursion in this scheme by explicitly threading a 'this' variable around in the code base. A subclass takes the superclass 'obj' and arranges that any unknown method is sent to the superclass function. For this to work, you have to extend func obj to also take a 'this' parameter and then construct a tie-the-knot passing obj to itself.

And where does that leave 9? Well, any system whose semantics obeys the above scheme is a 9. Of course, for details, you would have to ask Rees himself.

--

J.

[Ugo Landini]

I think Go is as "Object Oriented" as most of the languages currently considered oo. Definitely not a pure OO a-la Smalltalk, but not that much different from Java.

Going on your object oriented solution approach, on which I completely agree, a counter example would be useful. For example, how many classic GoF patterns (the ones still valid and used today) are not easily implementable in Go? 

-- uL

Pragmatist

http://ugolandini.com

--

[Egon]

After trying to understand these concepts more than anyone should. I believe the majority arguments come from trying to put OO on a binary scale. We are talking about paradigms, not complete strict definitions. Any strict definition will fail to capture a paradigm properly.

When I talk about paradigms, I mean the way you attack, analyse, modify the problem and solution. It's a way of thinking. And a programming language captures that paradigm as well as little you have to "translate" what you are thinking into code.

OO comes from the notion that you only have objects and you can manipulate them. Where each object has it's own behavior and state. You can make them communicate with each other. The main idea was a recursion on a computer. [http://www.vpri.org/pdf/hc_smalltalk_history.pdf]

Smalltalk’s design–and existence–is due to the insight that everything we can describe can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only through the exchange of messages. Philosophically, Smalltalk’s objects have much in common with the monads of Leibniz and the notions of 20th century physics and biology. Its way of making objects is quite Platonic in that some of them act as idealisations of concepts–Ideas–from which manifestations can be created. That the Ideas are themselves manifestations (of the Idea-Idea) and that the Idea-Idea is a-kind-of Manifestation-Idea–which is a-kind-of itself, so that the system is completely self-describing– would have been appreciated by Plato as an extremely practical joke [Plato].

In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing “computer stuff” into things each less strong than the whole–like data structures, procedures, and functions which are the usual paraphernalia of programming languages–each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computer all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly.

Now the OO-ness of a language depends how well you can take that way of thinking and translate it into code, and how well the code matches that way of thinking.

In that sense in Go, Java, C++, you first have to translate Objects into Classes/Types before you can write them down. Similarly you cannot arbitrarily modify Objects, you have to modify Classes. This is the translation layer, which makes it less OO -- however the way you think might still be OO. In Self and JavaScript you can create objects directly and manipulate them directly, which means less translation. In that sense, even Unreal Engine Editor is better in capturing the OO-ness of things, you can directly manipulate, make them interact etc.

You can try to pin down features that a language should have to support the OO-way, however all of them wouldn't be perfectly capturing the paradigm. Just as in "Blind men and an elephant" cannot aptly describe things, there's always something missing. Each such feature will capture some part of OO and some part of something else.

Let's take the right-panel in UE.

It represents very well an Object, you can modify it, you can change its behavior, you can make it communicate with some other Object ... however, there are no visible methods, inheritance, polymorphism ... but it still manages to capture essential parts of OO than some languages. When you modify, you think very concretely about objects, hell you even can see them being changed on the screen. Then again, I wouldn't want to write a web-server using it.

I find little use in finding how much OO-ness Go captures. I care about finding better ways of thinking about problems and more than that, about solving real problems.

+ Egon

[Henry Adi Sumarto]

Just like other programming paradigms, OOP provides useful heuristics in decomposing problems into structures that the machine can understand. However, OOP is not the only way and -depending on the problem- it is not always the best approach. Some people find it easier to solve problems by thinking in terms of objects, while others prefer to think in terms of data structures or something else. The problem with OOP is not the OOP itself, but the people who treat it as if it is the absolute correct way to programming. Some people are so engrossed with the intricacies of creating the "perfect" objects that they often lose sight of the actual problem they are supposed to solve.

I can't answer for Go, but I am rather glad that Go is not a strict OOP language. It seems to me that Go is designed as a "modern C", or what C language should have been in the modern world. Perhaps Commander Pike has a better answer for this. 

[Manlio Perillo]

Il giorno giovedì 7 gennaio 2016 22:20:01 UTC+1, Jesper Louis Andersen ha scritto:

On Thu, Jan 7, 2016 at 9:20 PM, Rob Pike <r...@golang.org> wrote:

I don't quite understand what is meant by 9.

It *probably* means that an object is a function (and closure) where it's first argument takes the method you are interested in:

http://play.golang.org/p/PUKfauf6Uv

Interesting example.

Here is an equivalent(?) version:

http://play.golang.org/p/LWdgcg0rEz

The code is equivalent because the state is inside the function. The difference is that it uses static typing.

> [...]

Regards  Manlio 

[⚛]

From my viewpoint:

1. Classes in standard OOP can model only a portion of all possible subset relationships. This may be a (subconscious) reason why some people do not consider OOP to be good.

2. In order to implement binary operations, one would need method dispatch on 2 arguments. Multiple dispatch is rare in OOP.

3. In most cases OOP does not improve program correctness, so there is little reason to switch from non-OOP to OOP style.

4. When OOP classes are combined with templates, such as in "List of E extends/implements Collection of E", the associated methods (get, set, add) in fact require two template arguments (R, W) instead of just one (E).

On Wednesday, January 6, 2016 at 6:33:13 PM UTC+1, Ghassan Karwchan wrote:

I should ask this question to the language designers,

That's me.

[Fino]

3. In most cases OOP does not improve program correctness, so there is little reason to switch from non-OOP to OOP style.

[fino] I think pure function is a way can improve program correctness; a function cannot refer a global var without declare it at input/output;  or, with the help of IDE/tool,  all the global var referenced by a function should listed out as it's input/output parameters. 

in real world, nobody coding this way, since it require much more typing. and function signature may need update due to function internal change.   

we may add some grammar sugar for pure function or similar ideas.    

BR-fino 

[kmdu...@gmail.com]

It's probably worth pointing out that this is addressed in Go's FAQ:https://golang.org/doc/faq#Is_Go_an_object-oriented_language

[Sean Russell]

On Wednesday, January 6, 2016 at 12:43:18 PM UTC-5, Roberto Zanotto wrote:

Depends what you mean with "OOP". Go is object oriented in the sense that you have objects with fields (structs), constructors and methods.

Go has constructors?  Where?

--- SER

[Bruno Albuquerque]

He probably means New*() style functions.

i.e.: https://golang.org/pkg/bufio/#NewReader

--

[chris dollin]

Don't expressions like TypeName{member: value, member2: value2 ...} count
as constructors?

Chris

--
Chris "allusive" Dollin

[Tyler Compton]

I would personally not call that a constructor. I've generally heard it referred to as a struct literal. I don't think Go really has constructors in the way most people think of them. The New* functions are not required to construct a non-nil object, since we have zero-values and struct literals. If Go has constructors, so does C and any other language where functions can be made to return an instance of a custom type, which dilutes the meaning of the word pretty considerably.

[Manlio Perillo]

Il giorno lunedì 11 gennaio 2016 19:05:23 UTC+1, Tyler Compton ha scritto:

I would personally not call that a constructor.

AFAIK, they are never called constructors.

However they are recognized by godoc, and handled in a special way:

https://godoc.org/os#File

> [...]

Regards   Manlio 

[⚛]

The need for transactional memory has its fundamental origin in the fact that to safely lock a list of objects (without deadlocking the program) the program needs to put the objects in order. However, neither the programmer nor the compiler can compute/predict which objects the program will be using at runtime, and therefore it is impossible to tell whether the program is free from deadlocks before it is run. Because the list of objects to lock is constructible only as the program is actually running, it will over time surely happen that the program will deadlock while it is run-by-run sampling its input. Because it is certain that over time the program will deadlock, the only option we are left with is to rewind the computation to the moment when the program was locking an object. Rewinding the computation and letting interfering parts of the program to finish their work will ensure that the program is free from deadlocks, thus it will ensure that the program is correct in the sense that it is free from deadlocks. Transactional memory improves program correctness by solving the deadlock problem. At the cost of somewhat slower run-time and/or compile-time performance when compared to not solving the problem.

Thank you for reading the above paragraph.

[Thomas Bushnell, BSG]

How would answering the question "Is Go object-oriented?" tell you anything about what Go is, how to use it effectively, or the rest? If we had an oracle to hand down the correct answer, what would we be able to do better after having the answer?

--

[Michael Jones]

“Why Go is not OOP” is an awkward question from the start. Rarely is a tool (language in this case) an enforcer of style or approach to usage of that tool. There have been good comments here, as before, about what OOP is (an even more ambitious question) and what an OOP language might be. I talk with Alan Kay from time to time and he says--as is relayed up thread--that he somewhat regrets coining the name “Object Oriented” because “Message Passing” is the stronger insight of Smalltalk, and those who copied the former and lost the latter have never had the real thing.

It interests me that the message passing style where, loosely, every invocation of an operation is actually a semantic decision controlled locally within the receiving “object”, is easily crafted in every programming language yet is an extended discussion about which languages have it and which do not. It is a fair question if you phrase it as “which languages do it intrinsically, naturally, and even (Smalltalk) to the degree of letting you redefine all primitive actions or even the dispatcher itself.” For this extreme question the answer is mostly Squeak/Smalltalk (http://squeak.org/). 

On the other hand, you can code such a dispatcher in BASIC or FORTRAN or anything else and have the same behavior as an application “layer” above the language so long as you don’t need to redefine the core languages functions, that is, using your "Send(+1) to Object(2)” rather than the native “1+2”. This is still Alan’s OOP, but in the programmer’s domain rather than the language’s. The importance of built-in is an open question. Generally, built-in means less flexible and that may or may not be a virtue for particular cases. Objective-C builds it in but not for 1+2, Smalltalk & Squeak take it all the way down. Go has reflection and interfaces, so you could go far this way if desired.

It’s all a matter of taste.

— 

Michael Jones, CEO  •  mic...@wearality.com  •  +1 650 656-6989 

Wearality Corporation  •  289 S. San Antonio Road  •  Los Altos, CA 94022

[sebastian...@gmail.com]

I completely agree. Moreover, another path towards OO as defined by Alan Kay (message passing + having the receiver decide how to react to it) is the one taken by Plan 9, with its use of the "file" concept as a universal abstraction for communication.  If one squints hard enough, Plan 9 processes look a lot like objects (and programs like classes). For example, just like objects, processes work by communicating with each other through a protocol (the file abstraction, and possibly 9P), they hide their internals from each other, each can be substituted by another process/program speaking and understanding the same protocol, and they can be composed into more complex structures (e.g. using the shell).

Go fits very well in this model, being so well-suited to writing server programs. I guess one way to think about it is that, when using Go, the OOP idea "surrounds" the single program, instead of being found inside.