clarifying Go FAQ: Is Go an object-oriented language?

[Ayan George]

The Go FAQ begins the answer to the question, "Is Go an object-oriented language," with, "yes and no."

  https://go.dev/doc/faq#Is_Go_an_object-oriented_language

The section goes on to say that Go has methods but there is no type hierarchy.  I guess those are the yes and no.

But I feel like programmers bringing their ideas from other less ambiguously object oriented languages like Java and C++ often have difficulty writing idiomatic Go.

If the answer to that question is "yes and no," it'd be less ambiguous to simply say, "no."  And that would be a definitive way of indicating that it woul be inappropriate to apply many patterns from object oriented languages to Go -- and to encourage people to accept Go for what it is.

Since receivers are parameters and one could use methods without using the method calling syntax at all, I'd suggest we'd classify it as a structured programming language with methods.

In either case, is there a way to make the FAQ more clear on this point?

-ayan

[Matt KØDVB]

The correct answer is actually “yes” because neither classes nor inheritance are necessary or sufficient for “object-oriented” programming.

https://www.youtube.com/watch?v=jexEpE7Yv2A

Sent from my iPad

On Nov 22, 2022, at 9:02 AM, Ayan George <ay...@ayan.net> wrote:



--
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/CAPSh2XBozm9bOe-O3SphET3A3wTif%3D0RiV%3D1Bw6GJkgT3wedLA%40mail.gmail.com.

[Robert Engels]

Go is not listed as an OO language on Wikipedia. 

Personally I think it is OO-like. OO typically has inheritance. 

There are also no “class variables” - only package level - which makes some encapsulation patterns harder (every class has to become a package). 

On Nov 22, 2022, at 9:06 AM, Matt KØDVB <ma...@k0dvb.com> wrote:

The correct answer is actually “yes” because neither classes nor inheritance are necessary or sufficient for “object-oriented” programming.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2B1E6084-E6F1-4B21-8ADF-06DA02A56966%40k0dvb.com.

[Robert Engels]

Also, there is an interesting point about OO languages made by Rob Pike (on the wiki page) that would also imply that Go is not OO by design. 

On Nov 22, 2022, at 9:43 AM, Robert Engels <ren...@ix.netcom.com> wrote:



[Jan Mercl]

On Tue, Nov 22, 2022 at 4:43 PM Robert Engels <ren...@ix.netcom.com> wrote:

> Go is not listed as an OO language on Wikipedia.

Check https://en.wikipedia.org/wiki/Go_(programming_language):
"ParadigmMulti-paradigm: concurrent imperative, object-oriented[1][2]"

> Personally I think it is OO-like. OO typically has inheritance.

Typically they may, but that's not the same as what a requirement
would be, right?

> There are also no “class variables” - only package level - which makes some encapsulation patterns harder (every class has to become a package).

No class has to become a package because Go has no classes. You may
think of what a "class" in Go means, but you have not defined that
idea and the language specification is somehow silent about Go
classes.

[Robert Engels]

The wiki OO page lists classes as a requirement - but not necessarily inheritance. Class variables require classes.

Also, your link does not work.

> On Nov 22, 2022, at 9:56 AM, Jan Mercl <0xj...@gmail.com> wrote:

> --
> 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/CAA40n-U%3DG8gqAZEHrnLUxbg5vsAcRkNV35c86c79xcrhSzLSWw%40mail.gmail.com.

[Thomas Bushnell BSG]

Asking "the definition of object oriented programming" seems a bad idea to me. Alan Kay invented the term, and he was pretty clear that C++ was not anything like what he had in mind, and yet, a lot of people think C++ is an object oriented language. I don't, as it happens.

Inheritance used to be thought of as quite fundamental, but not so much any more. I think that's probably right.

But here are some other things: object oriented languages are supposed to have object ubiquity. I think Stroustrup probably did not understand the point, and the designers of Java couldn't figure out how to make it efficient. So much for them. C++ gets so much wrong it hardly matters. But Java doesn't; it more or less regrets that it has non-object types. Go is very different however: Go does not regard interfaces as something that should be ubiquitous or feel bad when they aren't used. In fact, they are discouraged except when actually required.

Late binding is another key feature, one which again C++ mostly didn't understand the point of, and Java couldn't figure out how to implement efficiently, so everyone does "final" instead. Go does have late binding for interface method calls, but only on-demand.

Object oriented languages are generally either class-based or prototype-based. Go is neither, having nothing like classes and nothing like prototypes. For me, this is the most salient thing to keep in mind.

--
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/CAA40n-U%3DG8gqAZEHrnLUxbg5vsAcRkNV35c86c79xcrhSzLSWw%40mail.gmail.com.

[Matt KØDVB]

But see https://en.wikipedia.org/wiki/Self_(programming_language)

Self was considered an OO language back when I was a grad student and is still listed that way today, even though it has neither classes nor inheritance.

Anyway, my point would be that the term OO originates with Alan Kay and the team at Xerox PARC; Kay’s response to the OO flame wars was to de-emphasize classes and inheritance.

Of course, using his definition, neither Java nor Go would be “truly” OO since not all things use late binding :-)

Perhaps we can talk about class-based and non-class based OO languages?

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/A1F03B77-7CDC-46CC-B2E0-2C3C1B7DC966%40ix.netcom.com.

--

Matt

K0DVB

[Jan Mercl]

Hello Ian,

I have repeatedly asked this user to not use an email address that
spambots back for posting to this list - to no avail, unfortunately. I
think you are the moderator of this ML. I suggest banning posts from
<ren...@ix.netcom.com>.

Thanks for consideration.

To Robert (not CC'ing you for obvious reasons): You can create an
email for participating on this ML for free in minutes. There are
bazilions of such services available all over the Internet.

-j

---------- Forwarded message ---------
From: <ren...@ix.netcom.com>
Date: Tue, Nov 22, 2022 at 4:56 PM
Subject: Re: Re: [go-nuts] clarifying Go FAQ: Is Go an object-oriented language?
To: Jan Mercl <0xj...@gmail.com>


I apologize for this automatic reply to your email.

To control spam, I now allow incoming messages only from senders I
have approved beforehand.

If you would like to be added to my list of approved senders, please
fill out the short request form (see link below). Once I approve you,
I will receive your original message in my inbox. You do not need to
resend your message. I apologize for this one-time inconvenience.

Click the link below to fill out the request:

https://webmail1.earthlink.net/newaddme?a=ren...@ix.netcom.com&id=11ed-6a7e-3bda9c8e-8843-00144ff8e89f

[Robert Engels]

Why do you say that Java does not have late binding. It 100% does. In fact the JVM supports dynamic dispatch to make this as efficient as possible. Then the JIT optimizes it even more based on runtime behavior. 

On Nov 22, 2022, at 10:18 AM, Matt KØDVB <ma...@k0dvb.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANRS-2%2Bre6WUFT6tE8QinUZ-ipqLvwNTr2hoHNiD4H%3DwQ8T7HA%40mail.gmail.com.

[Robert Engels]

The wiki page on late binding discusses the Java facilities in depth. 

It also misses things like runtime proxy interfaces. 

On Nov 22, 2022, at 10:25 AM, Robert Engels <ren...@ix.netcom.com> wrote:



[Matt KØDVB]

I didn't say Java didn't have late binding, but that it didn't have late binding of every possible type (the "all things" in Kay's quote).

--

Matt

K0DVB

[Thomas Bushnell BSG]

Both Java and Go require that a method be instantiated in the declared interface of the type at compile time. This is contrary to the point of late binding.

In the case of Go, this cannot be detected, because everything is built together. But with Java, you cannot call a method on an object unless that method has already been defined. In other words, late binding supports the following order of things:

1) Write class A, with method X and only X. Compile it.

2) Write class B, which instantiates class A and calls method Y (which does not exist yet). Compile it.

3) Extend class A to add method Y. Compile it.

4) Execute class B.

Late binding says this should work, but the Java compiler will throw an error at step two. Go never throws that error, because Go only builds the whole program at once, so the partial compilations don't make sense.

In addition, any method marked final does not support late binding - indeed, this is the point of the keyword, and is why I remarked that this is because they couldn't figure out how to do it efficiently.

Thomas

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/A5532469-6B1D-4C18-8DBE-F03FD56E8830%40ix.netcom.com.

[Robert Engels]

What would be the purpose of writing B calling a method on A that doesn’t exist?

On Nov 22, 2022, at 10:36 AM, 'Thomas Bushnell BSG' via golang-nuts <golan...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxsQJu9KVOCR5xGK88yJ9w2FDNB9za_c%3DnvdGYZAvJbwWw%40mail.gmail.com.

[Thomas Bushnell BSG]

Late binding means you don't need to know the types of your parameters *at all* when you write a method call. If the language supported late binding, then you would be able to define all your variables as Object and *everything would continue to work*. 

In Go you could define everything as interface{} and then use small interfaces around every call:

foo.(interface{ Method() string}).Method()

In Java, you can use the reflection interface. In this sense, it is available "on demand", but that's not the same thing at all.

Both Java and C++ made the mistake of confusing a class with a behavior, and then using classes as names for behaviors.

[Robert Engels]

I do not know why the mailing list is set up as the sender is the user. Is should always have the sender be the list email and the name be the user, or the sender details included elsewhere. I don’t have this problem in any other lists.

People should be able to “reply” not “reply all” to respond to a group posting.

> On Nov 22, 2022, at 10:21 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
> Hello Ian,

> --
> 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/CAA40n-WXGFH5YVUG5%3DVHf6HE7Z%2BCmB-miqxNqOLhEO%3DNYCf6dA%40mail.gmail.com.

[Ian Lance Taylor]

On Tue, Nov 22, 2022 at 10:11 AM Robert Engels <ren...@ix.netcom.com> wrote:
>
> I do not know why the mailing list is set up as the sender is the user. Is should always have the sender be the list email and the name be the user, or the sender details included elsewhere. I don’t have this problem in any other lists.

We are just using ordinary Google Groups.

https://support.google.com/groups/answer/1046523?hl=en

I think many Google Groups work this way. I don't think we are an outlier.

Ian

[Ayan George]

Great points.

For me this is as much if not more of a communications issue than a technical one.  It seems like the definition of what an OO language is broad enough that we could go on forever about if Go is one.

The language developers can also choose to declare what it is meant to be definitively.

I feel like we should either say it is or it isn't OO and not equivocate in the FAQ.

I land on the side of simply saying it is not an OO language because of the conceptual baggage the notion carries.  I've personally seen these concepts misapplied to Go because if you squint... Go resembles other languages while being fundamentally different.

But in general, that lack of clarity seems un-Go like. I've always found the unwillingness to commit to an answer in the FAQ jarring.

[Dan Kortschak]

On Tue, 2022-11-22 at 10:16 -0800, Ian Lance Taylor wrote:
> On Tue, Nov 22, 2022 at 10:11 AM Robert Engels
> <ren...@ix.netcom.com> wrote:
> >
> > I do not know why the mailing list is set up as the sender is the
> > user. Is should always have the sender be the list email and the
> > name be the user, or the sender details included elsewhere. I don’t
> > have this problem in any other lists.

Robert, this has been an ongoing problem with mail from your address
for years for me, and I think that I have raised it in the past. It
breaks thread chains and drops messages. To illustrate, I'm reply to
the message from Ian because your message never made it to my inbox,
and his message is the only one that contains this text in my inbox.
Worse, his message is a thread-orphan. Interestingly, this does not
happen all the time, so I suspect that either your mail client is
flakey with regard to the References: header or you are using more than
one client. I don't recall seeing this behaviour from any other
sender's client on the list.

Dan

[Carla Pfaff]

On Tuesday, 22 November 2022 at 20:31:23 UTC+1 ay...@ayan.net wrote:

I feel like we should either say it is or it isn't OO and not equivocate in the FAQ.

Given the controversy here, I think "yes and no" is an appropriate answer. It also teaches people not to attach too much importance to vaguely defined buzzwords and categories, but to accept things for what they are and not try to pigeonhole them.

 

[Ian Lance Taylor]

On Tue, Nov 22, 2022 at 11:31 AM Ayan George <ay...@ayan.net> wrote:
>
> For me this is as much if not more of a communications issue than a technical one. It seems like the definition of what an OO language is broad enough that we could go on forever about if Go is one.
>
> The language developers can also choose to declare what it is meant to be definitively.
>
> I feel like we should either say it is or it isn't OO and not equivocate in the FAQ.
>
> I land on the side of simply saying it is not an OO language because of the conceptual baggage the notion carries. I've personally seen these concepts misapplied to Go because if you squint... Go resembles other languages while being fundamentally different.
>
> But in general, that lack of clarity seems un-Go like. I've always found the unwillingness to commit to an answer in the FAQ jarring.

I think the length of the discussion shows that the answer really is
"yes and no," because it depends on exactly what you mean by
"object-oriented." Since different people mean different things,
there is no clear answer possible.

It seems to me that you are suggesting that we make that answer
clearer for people who assume that either C++ or Java or both are the
definition of "object-oriented," but as we can see in this discussion
others disagree.

So I think the FAQ is saying the right thing. Rather than try to
tackle the definition, which is out of place in the Go FAQ, it tries
to briefly mention the salient parts of the language. Then it leaves
the decision as to whether that is the same as being "object-oriented"
to the reader. I don't see how we can do better than that.

Thanks.

Ian

[Robert Engels]

That seems nonsensical to me. What is the square root of a string?

Types aka classes define properties and behavior. 

Cars do not fly. Planes don’t use roads. Classes are abstractions that model required attributes that in turn compose a system to do useful work. Both boats and cars move. You can use a boat to get from a to b if there is no water. 

Go is OO like. Or Go is not OO. There’s reasoning to support both but don’t mangle OO to make the claim. 

On Nov 22, 2022, at 11:04 AM, 'Thomas Bushnell BSG' via golang-nuts <golan...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxtGgC0%2B7AZZM8j%2BKLZyouUgye8epmTquY4ZApFhrocMpA%40mail.gmail.com.

[Kamil Ziemian]

I think in the 1990s it was a debate if Lisp with Common List Object System (CLOS) is OOP language. The answer they arrive was something like that.

"No, if your definition of OOP is based on C++. But, why your definition of OOP should be based on C++?"

I think the same fits Go. Go is in many ways not a C++-like language, so if C++ is for someone golden standard of property X, then Go probably doesn't have X.

For these reasons I don't like question is language X is OOP? What matters for X = Go for me is that it provides you power to create new data types and abstractions that allow you to write reusable code. And it do it very well.

Best regards,

Kamil

[Kamil Ziemian]

"But I feel like programmers bringing their ideas from other less ambiguously object oriented languages like Java and C++ often have difficulty writing idiomatic Go."

I personally think that Java and C++ are less ambiguously OOP, only because we informally define OOP language as "language that is similar enough to C++ or Java". But this is like defining car as being something that looks like Mercedes and then discussing problem "Is Toyota similar enough to Mercedes, to be called a car?".

We also should notice that Alan Kay, man that coined term OOP, said that in his opinion there are two languages that can be consider as OOP: Smalltalk and Lisp. Notable, he didn't think that C++ and Java counts as such.

I have no doubts that Java and C++ programmers would have a problem, at the beginning, with writing idiomatic Go. This is because, in my opinion and in much simplifies form, C++ is about gathering stuff, while Go is about adding behavior and abstracting from that on. To make you thing more clear, in C++ you gather all you data and functions in one entity that you call class. In Go, what you should do it to define some struct that gather data and after that you add methods that provide functionality for this data. Distinction between gathering and adding functionality, is probably more about feeling that how things working under the hood, but because we feel or don't feel a language, we can or can't write idiomatic code.

Going back to comparison, when you add enough functionality to some type in Go by writing methods, you can use interface to abstract from gathered data, to write code that care only about functionality. If we can do the same things with two different types, we don't care what data is inside of them. We don't care is square and circle have the same underlying data. If all we need to know is how to take their area and how to move them, we can ignore what is under the hood.

At this moment I cannot thing about good equivalent of Go interface in C++ (I don't know Java). I would guess that, maybe, it is closer to C++ template and far cry from inheritance. But this is a topic for another time.

I hope I didn't mess these things up.

Best regards,

Kamil

[Rob Pike]

Let me ask, because I'm genuinely curious: Why does it matter? The labels we apply to things do not affect their function. Perhaps it affects how we think about them. Is that it?

-rob

[pat2...@gmail.com]

On Wednesday, November 23, 2022 at 8:27:57 PM UTC-5 Rob 'Commander' Pike wrote:

Let me ask, because I'm genuinely curious: Why does it matter?

I have to chime in that I agree with Rob that it doesn't matter.

In the 1990s, Object Oriented Programming was a huge fad, and in the consulting business (where I worked 

for decades) we had to be using the latest and greatest buzzword compliant tools. So everything was OOP.
But we quickly found that while Smalltalk was a great language to create a demo windowing system, it really did not

help writing most business applications.

The OOP fad is over. it really doesn't matter if go is an OOP language in 2022

 

[robert engels]

Human beings survive by classifications and compartmentalizing. Applying a label associates it with certain traits.

If someone said “I have a car for sale”, and you showed up and it had no wheels but a hull and a sail - you might be a bit upset.

Whether Go is a car or a boat is up to the experts.

On Nov 23, 2022, at 7:27 PM, Rob Pike <r...@golang.org> wrote:

Let me ask, because I'm genuinely curious: Why does it matter? The labels we apply to things do not affect their function. Perhaps it affects how we think about them. Is that it?

-rob

--
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/CAOXNBZS1vuSVcuHHgybwQH6e39ZRFH1eZaBUw%3D6nUj5sbpij%3DA%40mail.gmail.com.

[Holloway Kean Ho]

> If the answer to that question is "yes and no," it'd be less ambiguous to simply say, "no."  And that would be a definitive way of indicating that it woul be inappropriate to apply many patterns from object oriented languages to Go -- and to encourage people to accept Go for what it is.

Go does facilitate data grouping towards a subject or an object. In fact, even C does that. By grouping your data and methods towards an object, you attained OO. Hence, that's the "yes" part. It's all down to your languages' mastery.

The "No" part is that Go, C, and even Rust are not honoring "polymorphism" where this contradicts 1/6 main traits of the OOP (thanks god but that's not a dare). Polymorphism had been a known problem for bloating and causing unwanted spaghettied data definitions all over the places AND confuse basic programming paradigm like "bloating class vs when to use modules" case. These problems had been plaguing known languages like Ruby.

Since the "Car" object is mentioned, try updating "Car" definition after you defined 2000+ car derivatives and its sub-derivatives using polymorphism, deployed across the world. I'm pretty sure various depts will come after you (either by their incompetence in OOP or your update broke their derived definitions). Therefore, Go, C, Rust, and similar, as an improvement measure, all work towards OOP's compositions heavily.

Bottomline: it depends on how deep you understand OO paradigm and how far you mastered a programming language OR be blindly religious about OOP.

Site-note: fanatism never ends well anywhere in this world; it had been proven and tested by time.

> Cars do not fly. Planes don’t use roads. Classes are abstractions that model required attributes that in turn compose a system to do useful work. Both boats and cars move. You can use a boat to get from a to b if there is no water. 

> If someone said “I have a car for sale”, and you showed up and it had no wheels but a hull and a sail - you might be a bit upset.

> Whether Go is a car or a boat is up to the experts.

Your examples have something to do with the developer's psychological problem for failing to distingush between objects; not OO, OOP, or any programming languages. Neither Java or Go can rescue your situation. You should consider:

1. Review his/her manager's work ethics for possible abusement.
2. Get psychological help online for him/her.
3. Communicate with your PM for porject's risk mitigation.
4. Help him/her find a comaptible job.

Regards,

Holloway

[robert engels]

I am not sure what you are trying to say here. 

On Nov 23, 2022, at 8:36 PM, Holloway Kean Ho <hollowa...@gmail.com> wrote:

Your examples have something to do with the developer's psychological problem for failing to distingush between objects; not OO, OOP, or any programming languages. Neither Java or Go can rescue your situation. You should consider:

1. Review his/her manager's work ethics for possible abusement.
2. Get psychological help online for him/her.
3. Communicate with your PM for porject's risk mitigation.
4. Help him/her find a comaptible job.

I will say it another way:

I am offering you a Acme1000 and a Beta1000 - both cost $100.  Which do you want?

Clearly you would ask: 1) Do I need either of these? 2) What is the difference between the two?

Labels/common language is what allows societies to exist. As in this case, I believe your ESL has caused you to issue some statements above that make it difficult for people to understand what you are trying to say and may even interpret them to mean you are a rude person that should be ignored.

Whether applying the OO label to Go makes sense depends on what you believe OO means. If you don’t have an accepted definition of a OO language, nor a complete understanding of Go itself - it is impossible to say that applying the label is correct or not. Ample evidence has been given that the definition of OO is “not universally accepted”.

If you claim that labels are only useful when “it’s obvious what it is” - how do you determine it is obvious? Your personal experience/knowledge? An accepted “reference guide”?

[Ayan George]

Yes -- that's it exactly!

I think the amount of hair-splitting over what is an object oriented language
is reason to say it *isn't* an Object Oriented language at all.

This variety of definitions means Go will probably not meet anyone's
expectations. It's useless to talk about it in terms of something that we
can't clearly define.

Practically, I think the phrase "Object Oriented" is almost synonymous with
Java and maybe C++ and C#.

If you kind of load that context in your mind as you read, it becomes:

Is Go an Object Oriented Language Like Java (or C++ or C#...)

Answering "yes" is almost permission to apply patterns from those languages to
Go as well. And that's rarely a good fit. We've all seen it: A Go code base
written with Java idioms or with C++ idioms, etc.

Saying "yes or no" is a non-answer. :)

Saying "yes" opens the possibility for people falsely attributing things to Go.

Saying "no" encourages people to abandon their pre-conceived notions and take

Go for what it is.

I recognize this is a kind of soft issue that is prone to bikeshedding. I
considered it settled when Ian answered.

-ayan

[Holloway Kean Ho]

> I think the amount of hair-splitting over what is an object oriented language is reason to say it *isn't* an Object Oriented language at all.

Given the FAQ header's "Is Go an object-oriented language? emphasizing that "object-oriented" is in lowercase, not the titlecase "Object-Oriented" that generally points to OOP context: it is why I treat the FAQ "yes and no" as an acceptable answer. 

My exhibits:

1. Linux kernel is mainly based on C, but it managed to grouped its driver data into an object-oriented way (various types of IO IP products) - See (https://elixir.bootlin.com/linux/latest/source/drivers)
2. Go's various standard packages like (url, strings, http, etc), they're oriented to a specific data type. See URL package (https://pkg.go.dev/net/u...@go1.19.3#URL)
3. Unlike C, Go and Rust has interface methods that behaves similar to an OOP Class (see URL in #2).

Therefore, you can't say they aren't OO but you certainly can say they incompatible with the conventional OOP.

If an amendment is required, I believe the missing context (OO in plain English or OO in OOP) has to be explictly clarified.  As far as definitions goes, they are 2 different contexts. OOP is an implementation/subset of OO.

One thing for sure: I agreed that the mentioned FAQ header is a bit cheesy.

>> Cars do not fly. Planes don’t use roads. Classes are abstractions that model required attributes that in turn compose a system to do useful work. Both boats and cars move. You can use a boat to get from a to b if there is no water. 

>> If someone said “I have a car for sale”, and you showed up and it had no wheels but a hull and a sail - you might be a bit upset.

>> Whether Go is a car or a boat is up to the experts.

> Labels/common language is what allows societies to exist. As in this case, I believe your ESL has caused you to issue some statements above that make it difficult for people to understand what you are trying to say and may even interpret them to mean you are a rude person that should be ignored.

> If you claim that labels are only useful when “it’s obvious what it is” - how do you determine it is obvious? Your personal experience/knowledge? An accepted “reference guide”?

If I re-phrase one of your example, it would be:

"I have a car (object) for sale" -> "Toyota Camry" (label) vs. "Tesla Model S" (label) vs "AeroMobil 3.0" (label)

1. They are all unilaterally labelled as "car". Can you say all 3 of them are not object-oriented towards "car" definition? (OO)
2. When and how should we specify a "car" across automobile and aeronautics industries? Electric motors vs ICE engine? engine capable of flying + on the road? defined, ratified, and enforced by who or whom? (OOP)

I still don't see the examples ("car vs boat", "Acme1000 vs Beta1000") relevancies. However, given the tone and the frames of those examples, I did observed a known burnt-out pattern of a developer overworked for a long time to the point where a "car" and a "boat" can no longer be cognitively differentiable eventhough their clearly different in nature, unrelated to the labelligng topic at all. This is a severe symptom and I called out the psychological matter.

Given the recent mass layoffs, I'm not surpirsed some managers can pressure the team to perform beyond limits. No ill intent. Sorry if you take it another way.

Peace. Cheers!

Regards,

Holloway

[robert engels]

Your reading comprehension skills need some work.

The point of “labels matter” was answering Rob Pike’s “why does it matter” question.

I used extremely different objects - yet both modes of transportation - intentionally to highlight the need for common definitions in order to communicate.

The car & boat are very easy to differentiate because it is commonly understood what traits each of those labels imply.

If you change the objects to Go and Java and ask which languages are OO you get different opinions. If an OO programmer expects an OO language to have inheritance and late binding, it won’t be Go. Similarly, if I go to buy a car and someone tries to sell me a boat with the understanding I was simply looking for a mode of transportation  it won’t fly.

I think the fact that you immediately jump to insulting language says more about your state. Maybe you need a break. Or at least a lesson in manners.

--
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/730c3130-e4e9-4db5-87f6-589567f86fben%40googlegroups.com.

[Kamil Ziemian]

" Let me ask, because I'm genuinely curious: Why does it matter? The labels we apply to things do not affect their function. Perhaps it affects how we think about them. Is that it?"

My point of view is that. In the moment when you learn the flow of language X, it doesn't matter. But, it is not a thing that you get without some work and many mistakes done along the way.

Before that labels are important on at least two levels.

1) As promotion/marketing tool. If someone think that OOP is cool, he would here that language X is OOP he would think "O, new language doing OOP in new cool way. Maybe I should learn it? You know, OOP is cool".

2) As a guide for the people what to think and how to use about language X. In the original post was already mention, that C++ and Java programers have problem with writting good code in Go. My feeling is that, they try write C++/Java code in Go, "they all OOP languages", which is missing the point.

Hard truth is that for most people, me included, our ways of thinking (about everything) and of coding ossified and stiffen after a time and we need to put quite a work to make them fresh and flexible again. To use somewhat radicolous example, if you put label "bike" on washing machine some people will try to ride to work on it and they will complaine, that is not very good bike.

Best regards,

Kamil

[Kamil Ziemian]

I will start with cautionary tell. At one of his public talks Bjarne Stroustrup in some way, admited that he made a very bad job when teaching people C++ and now we must live with many bad practices being a norm and even adviced as good practices. In Stroustrup words

"I didn't care about "Let them hear your message", "Show them the vision". I was thinking, that it just a rabbish. It is not.".

I would classify all questions like "Is Go OOP language?" in the category  "Let them hear your message". People like Rob Pike, Robert Griesemer and Ian Lance Taylor probably don't need any labels like that, since, at the end of the day, these labels answer very little important questions and they can just go to the heart of the matter. But, let face it, very few people is on thier level, especiall among newcommers.

We know how much hot topic was "generics in Go" (one of the less know part of the language in may case), when Robert Griesemer can just say in his talks about adding them to Go "Generics are just glorified (type checked) macros" (GopherCon 2020). For me it is one of the signs of how good people like Griesemer are: for them the many hottest topics are just "no big deal".

Previously, rightly, it was observed that 1990s OOP was a huge fad. Unfortunetly, it is still big fad in many places. I'm from Poland, where the most popular book, which I read myself as the beginner, in the last 30 years on C++ is written with this OOP fad spirit. And from many reasons, people in Poland in the age span 15-25 still today starts they programming journej with this book. People raised in such enviroment, when comming to any other language will be asking "Is it OOP?". Languages for which answer is "Yes" will be classified as "cool" and these for which answer is "No" as "Uncool, outdated and passe". Which is rabbish, but new people just don't know better.

If this discussion about "Is X OOP language?" was just about which labels applies where, I would probably shrug and go do more important things. But, I consider it a case of "Let them hear you message" to use this slogan, and I happy to spend some of my time expleining people who ask what I understand about Go. For the same reason, I consider spending time in this thread, a things that can lead to something valuable.

Best regards,

Kamil

[Kamil Ziemian]

"Saying "yes or no" is a non-answer. :)"

From people new to coding, I guess so. For people with good background, this is a good answer, since rest of the FAQ entry explain enough that they can say "Ok. I think I'm getting it.". BTW in FAQ it is "Yes and no.".

So true question is: who is asking and how detailed answer he or she needs?

Best regards,

Kamil

[TheDiveO]

Reading the "yes and no" part as a newcomer to Go actually made me snigger and I though that this kind of answer shows a thorough and differentiated thinking not shy of dealing with complexity as it is without trying to flee into simple and useless label simplification. IMHO the problem is not seeing concepts like OO as a fad, but instead the people struggling with complex topics and fleeing into blissful simplification. Maybe I should throw in here "embedding" so we might save on house heating this time of year.

[robert engels]

OO as a fad? This is Thanksgiving not April Fool’s Day.

--
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/374bd837-f017-4325-b96a-6b0457a757a0n%40googlegroups.com.

[Sven Anderson]

Ayan George <ay...@ayan.net> schrieb am Di. 22. Nov. 2022 um 16:03:

The Go FAQ begins the answer to the question, "Is Go an object-oriented language," with, "yes and no."

[…]

But I feel like programmers bringing their ideas from other less ambiguously object oriented languages like Java and C++ often have difficulty writing idiomatic Go.

You seem to assume that changing that part of the FAQ could reduce the likelihood of bad practices. I don’t believe that would have a real impact. IMHO the bad practices come from whatever they learned before in other languages, and a „no“ would not stop them.

Cheers,

Sven