I really hope my negative perception of your attitude stems from a language barrier. To clarify, I was trying to state that you can write Java without using a framework, just as you can write Go using a framework. Using a framework has nothing to do with OOP. Even the term framework is misleading - there are many large “libraries” in C that I would consider a framework.
> On Jan 1, 2021, at 5:05 PM, Space A. <reexist...@gmail.com> wrote: > > 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 > <mailto: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 >> <mailto: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 > <mailto: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 > > <https://groups.google.com/d/msgid/golang-nuts/CADKwOTf6om7HLUjXPeyqCW9rRpC0ffiaOO5BY7OEwQ1VQ4jo0g%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/24AD21D2-F4D6-4EA1-9D19-98D84046327C%40ix.netcom.com.
