That's fine so we disagree on that. An you also seem to disagree on FAQ (I know you read it, that's for other readers): https://golang.org/doc/faq#Is_Go_an_object-oriented_language
Won't say how many years I have because I hate these talks and I used to think I'm still 20 yo =) But yea, I remember the times when "Assembly" was "Assembler". пт, 1 янв. 2021 г. в 21:44, robert engels <reng...@ix.netcom.com>: > 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>: > >> 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/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/CADKwOTfYSgz2yR9j_x970hgnCzbU9C1cEFVqqjRg5YOWczPuYQ%40mail.gmail.com.
