"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
wtorek, 22 listopada 2022 o 16:05:25 UTC+1 ay...@ayan.net napisał(a):

>
> 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
>
>
>
>

-- 
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/dae9f6d6-d5f7-4242-9b14-4c95d42abdc9n%40googlegroups.com.

Reply via email to