You keep replying with random sentences no matter what I say, just combining known words in random phrases. Okay, but please put me out of your list, cause I have better games to play.
сб, 2 янв. 2021 г. в 00:50, robert engels <reng...@ix.netcom.com>: > 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>: > >> 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> 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>: >> >>> > 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 >> <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. > 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/CADKwOTf6om7HLUjXPeyqCW9rRpC0ffiaOO5BY7OEwQ1VQ4jo0g%40mail.gmail.com.
