Actually not "people mean the literal opposite of what they say", but "people interpret wrongly when trying to read literally". At least I can imagine myself saying something similar to "Go is more object oriented than ..." if it's not regarding general classification of languages. Maybe I even did that, lol.
пт, 1 янв. 2021 г. в 17:30, Axel Wagner <axel.wagner...@googlemail.com>: > On Fri, Jan 1, 2021 at 3:04 PM Space A. <reexist...@gmail.com> wrote: > >> > I don't see a lot of room for interpretation here. >> >> Well, I do. I do believe if you truly think he meant "Go is OOP language" >> and continue insisting you are wrong. >> > > Okay. I don't believe "people mean the literal opposite of what they say" > is a POV that can be argued with. > > >> >> 1. First of all I feel it's more rhetoric, it's same as "Less is >> exponentially more", and "[Go] ... Arguably more object oriented than say >> Java or C++ ". I believe if you think logically "less" could not be "more", >> right, and you wouldn't insist on that? Same goes to the statement that Go >> is more object oriented. What I think he meant was "Go has even better >> compatibilities even for OOP because of composition" which also in line >> with what I said that you can use ANY language to write OOP program. >> 2. There is FAQ question and answer, and I do believe Rob took part in >> answering FAQ, and this one in particular. >> >> Anyways as you said in the beginning of thread, Go is no a religion, Rob >> is not Jesus, he is alive and he can explain his position if it makes any >> sense. Maybe I'm wrong and don't understand something, that's possible. So >> I'm not arguing for the sake of arguing. >> >> >> >> >> >> пт, 1 янв. 2021 г. в 16:48, Axel Wagner <axel.wagner...@googlemail.com>: >> >>> 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/CADKwOTdKag%2BKA_QhNvVeVKdi8jqVPumJWj4LSXwx9vRYJ-Fu-A%40mail.gmail.com.
