I hate to chime in here, but Go by the industry accepted definition - at least based on my 30+ years experience - is that Go is clearly an OOP language.
It has “instances” coupled with “behavior”. That is, given a struct instance I can call a method “on it” declared by its definition. Other OOP languages don’t require the definition and can create instance methods dynamically. This differs from a language like Assembly, C, Cobol (prior 2002), or Fortran (prior 2003). For example, C has instances but no methods. > On Jan 1, 2021, at 6:56 AM, 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. 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. > > > 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 =) > 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. > > You disagree on a statement that composition is not inheritance? Or that > inheritance implies type hierarchy and vise versa? Maybe you disagree with > Rob Pike who made statements quite similar to what I said regarding > composition in his quote I given above? Or just arguing for arguing? I just > don't understand your pathos here. > > > 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: > 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. > > > 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). > > > > > пт, 1 янв. 2021 г. в 05:16, Axel Wagner <axel.wagner...@googlemail.com > <mailto:axel.wagner...@googlemail.com>>: > On Fri, Jan 1, 2021 at 1:23 AM Space A. <reexist...@gmail.com > <mailto: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 > <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 > <https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html> > > > > > > чт, 31 дек. 2020 г. в 23:27, Alex Besogonov <alex.besogo...@gmail.com > <mailto: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 > <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 > <mailto: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 > <mailto: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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CADKwOTcd%2Bm49WKzre_qdEP-HhcqzMOnTZR%2Bbcx_aqJiBJt2deg%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CADKwOTcd%2Bm49WKzre_qdEP-HhcqzMOnTZR%2Bbcx_aqJiBJt2deg%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/CB6023BD-76B0-43B1-B4FE-7CBC5EC42667%40ix.netcom.com.
