On Fri, Jan 1, 2021 at 1:57 PM Space A. <reexist...@gmail.com> wrote:

> > Javascript is an incredibly popular language with non-inheritance OOP.
> Or, at least, no inheritance at the type-level (so either way, invalidating
> your statement that OOP is about type-hierarchies).
>
This is debatable but JS is a non-OOP language.
>

That's certainly a valid opinion to hold. I don't believe it, empirically,
agrees with the common wisdom around it, though.


> And yet if you wonder, there is no definition of what OOP language is.
> Give it any, I don't mind. But it seems to most of us it's quite clear (by
> major examples like C++ or Java) until we start arguing just for arguing.
>

With this, I agree. Note, again, that it doesn't actually *matter* for the
question of whether or not Go should get generics, whether we call it an
OOP language or not. And yet, it has become a point of argument in this
thread - AFAICT, purely for the sake of arguing.

> Repetition does not make a false statement true. Instead of copy-pasting
> yourself, it would be prudent to cite sources. For example, is there any
> text book that agrees with your definition of OOP?
> What exactly you disagree on? I will copy and paste once again for your
> convenience =)
>

There really is no need (though I recognize what you are trying to do). Let
me quote a couple of your statements that I disagree with:
• "Go doesn't have classes and is not an OOP language."
• "Oh my... It is pure sophistic nonsense. OOP is all about inheritance.
Not just whether you have "objects" in a language spec or not."
• "As I said, OOP (if we talk about language, not a program written in OOP
paradigm, because you can use ANY language for that) is all about
inheritance."

And in the interest of clarity and to illustrate that I'm not just trying
to argue for the sake of argument: I do agree with you that Go favors
composition over inheritance. And I do agree that inheritance based OOP
prioritizes type-hierarchies.


> Maybe you disagree with Rob Pike who made statements quite similar to what
> I said regarding composition in his quote I given above?
>

If we are making an appeal to authority, I thnik you'll find he made
statements that directly contradict the ones I quoted above as disagree
with. And he made statements that support the ones I agree with.


> That's ridiculous. There is a question in FAQ. And answer you are aware
> of, which says Go is not OOP, which Rop Pike for sure aware of as well. And
> his wording in that video means not how you trying to interpret.
>

His verbatim quote is "Go is a profoundly object oriented language.
Arguably more object oriented than say Java or C++". That clearly
contradicts your statement that Go is not an OOP language. He also goes to
great length to say that Go does not have inheritance (in favor of
composition), which, together with the first one, clearly implies that he
is contradicting your assertion that "OOP is all about inheritance".

I don't see a lot of room for interpretation here.

> But either way, if you don't mind me asking: What exactly does any of
> this have to do with generics?
> Good question, ask Alex Besogonov, because he started this arguing that Go
> has classes (opponent meant he doesn't want making Go like C++/Java).
>

If we are pointing fingers, the statement he reacted to was "The real value
for Go is it's simplicity, avoidance of generics and avoidance of classes",
not "I don't want to make Go like C++/Java". And Alex put his statement
into parenthesis, clearly indicating that he considers it only a minor
side-point.

But, if we agree it doesn't matter, we should probably just drop it.



>
>
>
>
> пт, 1 янв. 2021 г. в 05:16, Axel Wagner <axel.wagner...@googlemail.com>:
>
>> On Fri, Jan 1, 2021 at 1:23 AM Space A. <reexist...@gmail.com> wrote:
>>
>>> > Sorry to disappoint you (actually, no, not sorry) but OOP has nothing
>>> to do with inheritance. It's a common feature in object-oriented
>>> programming but it's not essential.
>>> > Moreover, Go has inheritance as well (struct embedding and interface
>>> inheritance), making it a fairly typical example. The only significant
>>> difference is that Go has structural typing, instead of manually
>>> declaration of implemented interfaces.
>>>
>>> You don't disappoint me by repeating wrong statements.
>>>
>>> As I said, OOP (if we talk about language, not a program written in OOP
>>> paradigm, because you can use ANY language for that) is all about
>>> inheritance. Period. Proof - take any major OOP language and see how it's
>>> done, what's in its heart.
>>>
>>
>> Javascript is an incredibly popular language with non-inheritance OOP.
>> Or, at least, no inheritance at the type-level (so either way, invalidating
>> your statement that OOP is about type-hierarchies).
>>
>> Secondly, and I copy-paste myself here:
>>> Classes (like in Java) vs structs (like in Go) is about inheritance vs
>>> composition, not about attaching fields and methods. Inheritance implies
>>> type hierarchy, child and parent, virtual functions, abstract and final
>>> implementations and so on so forth to keep this all of this manageable.
>>>
>>
>> Repetition does not make a false statement true. Instead of copy-pasting
>> yourself, it would be prudent to cite sources. For example, is there any
>> text book that agrees with your definition of OOP?
>>
>> If you don't understand what it means, please study a little bit (with
>>> all respect and blabla, I also learn all the time). Because these two
>>> approaches are different.
>>>
>>> Here is some small quote and link which I think can help:
>>>
>>> My late friend Alain Fournier once told me that he considered the lowest
>>>> form of academic work to be taxonomy. And you know what? Type hierarchies
>>>> are just taxonomy. You need to decide what piece goes in what box, every
>>>> type's parent, whether A inherits from B or B from A.  Is a sortable array
>>>> an array that sorts or a sorter represented by an array? If you believe
>>>> that types address all design issues you must make that decision.
>>>>
>>> I believe that's a preposterous way to think about programming. What
>>>> matters isn't the ancestor relations between things but what they can do
>>>> for you.
>>>>
>>>> That, of course, is where interfaces come into Go. But they're part of
>>>> a bigger picture, the true Go philosophy.
>>>> If C++ and Java are about type hierarchies and the taxonomy of types,
>>>> Go is about composition.
>>>> Doug McIlroy, the eventual inventor of Unix pipes, wrote in 1964 (!):
>>>>
>>>> We should have some ways of coupling programs like garden hose--screw
>>>> in another segment when it becomes necessary to massage data in another
>>>> way. This is the way of IO also.
>>>>
>>>> That is the way of Go also. Go takes that idea and pushes it very far.
>>>> It is a language of composition and coupling.
>>>> The obvious example is the way interfaces give us the composition of
>>>> components. It doesn't matter what that thing is, if it implements method M
>>>> I can just drop it in here.
>>>> Another important example is how concurrency gives us the composition
>>>> of independently executing computations.
>>>> And there's even an unusual (and very simple) form of type composition:
>>>> embedding.
>>>> These compositional techniques are what give Go its flavor, which is
>>>> profoundly different from the flavor of C++ or Java programs.
>>>>
>>>
>> One thing that is conspicuously absent from this quote, of course, is the
>> term "Object oriented programming" (or even just "Object"). FTR, if you
>> quote Rob Pike, you should also be aware that he has always staunchly
>> defended the stance that Go is an OOP language:
>> https://www.youtube.com/watch?t=750&v=rKnDgT73v8s
>>
>> But either way, if you don't mind me asking: What exactly does any of
>> this have to do with generics?
>>
>>
>>>
>>> https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html
>>>
>>>
>>>
>>>
>>>
>>> чт, 31 дек. 2020 г. в 23:27, Alex Besogonov <alex.besogo...@gmail.com>:
>>>
>>>> On Wednesday, December 30, 2020 at 12:23:35 PM UTC-8 Space A. wrote:
>>>>
>>>>> > OOP isn't specific about how inheritance is handled (or if it is
>>>>> even supported)
>>>>> Oh my... It is pure sophistic nonsense. OOP is all about inheritance.
>>>>> Not just whether you have "objects" in a language spec or not.
>>>>>
>>>> Sorry to disappoint you (actually, no, not sorry) but OOP has nothing
>>>> to do with inheritance. It's a common feature in object-oriented
>>>> programming but it's not essential.
>>>>
>>>> Moreover, Go has inheritance as well (struct embedding and interface
>>>> inheritance), making it a fairly typical example. The only significant
>>>> difference is that Go has structural typing, instead of manually
>>>> declaration of implemented interfaces.
>>>>
>>>> > But on the topic of generics, this entire thread seems alarmist.
>>>>> Generics will open a huge door for libraries to be written that will make
>>>>> our lives easier.  I'm thinking specifically about data processing and
>>>>> machine learning.  A lot of devs use Python right now for this which leads
>>>>> to duplication of code across languages.  Complex algorithms will be able
>>>>> to be shared without hacky type conversions wrapping every function call.
>>>>> Who is "yours"? You talk about Python so just go ahead and use Python
>>>>> if it serves you, convince your team that Python is better, whatever.
>>>>>
>>>> You know that this argument can be applied to you as well?
>>>>
>>>>
>>>>> среда, 30 декабря 2020 г. в 22:46:12 UTC+3, nichol...@gmail.com:
>>>>>
>>>>>> OOP isn't specific about how inheritance is handled (or if it is even
>>>>>> supported).  The basic definition is objects with fields and methods, and
>>>>>> being able to address the itself (typically using 'this' or 'self', but 
>>>>>> Go
>>>>>> is unique in that you define what to call the object).  It does 
>>>>>> composition
>>>>>> differently than most languages, but the functional needs are met.
>>>>>>
>>>>>> But on the topic of generics, this entire thread seems alarmist.
>>>>>> Generics will open a huge door for libraries to be written that will make
>>>>>> our lives easier.  I'm thinking specifically about data processing and
>>>>>> machine learning.  A lot of devs use Python right now for this which 
>>>>>> leads
>>>>>> to duplication of code across languages.  Complex algorithms will be able
>>>>>> to be shared without hacky type conversions wrapping every function call.
>>>>>> We'll be able to use things like trees as simply as we use maps or 
>>>>>> slices.
>>>>>> I don't think we'll see the language turn into the grossness that is Java
>>>>>> or C++ because of it.
>>>>>>
>>>>>> On Wednesday, December 30, 2020 at 4:27:15 AM UTC-8 Space A. wrote:
>>>>>>
>>>>>>> Go doesn't have classes and is not an OOP language.
>>>>>>>
>>>>>>> Classes (like in Java) vs structs (like in Go) is about inheritance
>>>>>>> vs composition, not about attaching fields and methods. Inheritance 
>>>>>>> implies
>>>>>>> type hierarchy, child and parent, virtual functions, abstract and final
>>>>>>> implementations and so on so forth to keep this all of this manageable.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov:
>>>>>>>
>>>>>>>> Please, stop being so condescending to newcomers and
>>>>>>>> non-professional developers. Generics as uses by end-users will improve
>>>>>>>> their experience, not make it harder.
>>>>>>>>
>>>>>>>> (And what is this obsession with "classes"? Go has them - structs
>>>>>>>> with methods are classes).
>>>>>>>>
>>>>>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "golang-nuts" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/golang-nuts/LEEuJPOg0oo/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> golang-nuts+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/golang-nuts/7b58c437-4507-4d75-b0a2-de7b0ba8b58dn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/7b58c437-4507-4d75-b0a2-de7b0ba8b58dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CADKwOTd4%3DiPTtyBRhFW-aQFoEMd0jsVzrSUhTb2PtLyMWKxHiQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/golang-nuts/CADKwOTd4%3DiPTtyBRhFW-aQFoEMd0jsVzrSUhTb2PtLyMWKxHiQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEnLjQP%3D762dD%3DbNumtXF5QovXyA3PoFqmv__5o0wfOsg%40mail.gmail.com.

Reply via email to