Those concerns are unrelated. There are plenty of frameworks in Go as well. You can create frameworks without using inheritance.
> On Jan 1, 2021, at 2:51 PM, Space A. <reexist...@gmail.com> wrote: > > Composition is just a principle, which can be implemented on different layers > by different ways. I'd say in Java you will be forced not only to follow OOP > (with inheritance and all of that ofc) even if you don't need it, you will > end up writing in some framework and that framework will become your > language, rather than vanilla Java, unless you're doing simple examples for > students. First question Go newcomers ask on forums which framework I should > use for my application. > > > > пт, 1 янв. 2021 г. в 23:27, robert engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>>: > You can write Java (or any other OOP with inheritance) using composition > rather than inheritance. Much of the Java stdlib uses both. It can be argued > that most usages of anonymous inner classes are composition rather than > inheritance. > >> On Jan 1, 2021, at 1:59 PM, Space A. <reexist...@gmail.com >> <mailto:reexist...@gmail.com>> wrote: >> >> > 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 >> <mailto: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 >> <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.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 >> <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 >> <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/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 >> <mailto: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 >> >> <https://groups.google.com/d/msgid/golang-nuts/CADKwOTcr3WOWf%3DuvxtsCYbG95LkvTqqDMuYroMrdFGAkEr%2BzLQ%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/CADKwOTcq%3DOTgSsVNDqqFcKaM8AqFFpjRivJq93ETKFbeV9SD5Q%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CADKwOTcq%3DOTgSsVNDqqFcKaM8AqFFpjRivJq93ETKFbeV9SD5Q%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/071E5BA1-C863-409F-980C-730437D18AD8%40ix.netcom.com.
