> Wait, I think I get it. Are you making a distinction between object oriented /languages/ and object oriented /programs/ (which may or may not be written in an object oriented language)? You are absolutely correct, my friend, so you see, OOP is just a paradigm in software development. Program can be entirely OOP, or partially, such as module, or library. And you have tools such as programming languages. When these languages provide you with instruments for building your OOP program *out of the box*, being a first-class citizens, you could call that language OOP. Key feature of major OOP languages is inheritance and all supporting stuff. But you can use non-OOP language such as C, just that you will need to add some moving parts yourself instead of using what's given by language.
Same with CSP. Go is often called a CSP language, or language with CSP capabilities, because it has all needed features, such as goroutines and channels out of the box as first class objects. But this doesn't mean you cannot write CSP program in any other language, you can, but you will sometimes have to invent a wheel. > For example, from my interpretation of your definition, Java and C++ would be considered object oriented languages, because they favor class inheritance over composition. But a language like Scheme or JavaScript would not be considered an object oriented language because they do not have traditional class inheritance. Exactly. Thank you for giving me hope that at the end at least some of us living on the same planet. пт, 1 янв. 2021 г. в 19:07, Beka Westberg <bekawestb...@gmail.com>: > > 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. > > Wait, I think I get it. Are you making a distinction between object > oriented /languages/ and object oriented /programs/ (which may or may not > be written in an object oriented language)? > > For example, from my interpretation of your definition, Java and C++ would > be considered object oriented languages, because they favor class > inheritance over composition. But a language like Scheme or JavaScript > would not be considered an object oriented language because they do not > have traditional class inheritance. > > However, it seems like you are saying that you can write an object > oriented /program/ in any of the above languages? Each of the above > languages allows you to create "things" that have internal mutable state, > and can receive messages, which seems like a pretty good definition of an > object :D Hence, object oriented programming is possible. > > I don't really have an opinion on this. I just want to know if my > interpretation of your opinion was close, or way off base hehe. > > On Friday, January 1, 2021 at 6:05:07 AM UTC-8 Space A. wrote: > >> Ok I see you change a little bit your position, so I only comment on this: >> >> > 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. >> >> Well, I do. I do believe if you truly think he meant "Go is OOP language" >> and continue insisting you are wrong. >> >> 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.wa...@googlemail.com>: >> >>> On Fri, Jan 1, 2021 at 1:57 PM Space A. <reexi...@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.wa...@googlemail.com>: >>>> >>>>> On Fri, Jan 1, 2021 at 1:23 AM Space A. <reexi...@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.be...@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...@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...@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 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/9be2bdba-7e5d-42c2-be19-3975e0d51fbcn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/9be2bdba-7e5d-42c2-be19-3975e0d51fbcn%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/CADKwOTcr3WOWf%3DuvxtsCYbG95LkvTqqDMuYroMrdFGAkEr%2BzLQ%40mail.gmail.com.
