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
"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
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
" 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
Rob Pike 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?
>
Yes -- that's it exactly!
I think the amount of hair-splitting over what is an object
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
"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