I take offense to that. I apologized for my statement that was worded more
harshly than intended. But if you think that Go is beyond criticism just
because of ??? Anything??? Go is a GREAT tool for many classes of applications,
but it is certainly not appropriate for all use cases. Maybe with open
criticism it could get there, but I don’t think your attitude will help it. I
am certainly not the first nor the last to highlight many deficiencies in Gos
design. That’s the great thing about software though, it is malleable.
Sent from my iPhone
> On Sep 23, 2018, at 9:01 AM, Lucio De Re <lucio.d...@gmail.com> wrote:
>
> I take exception to that statement, your notion of "understood
> languages much better" doesn't parse in light of the fact that you are
> here, debating the merits of Java in the primary Go forum instead of
> writing wonderful code using the language you respect so much.
>
> That's either hypocritical or merely absurd in addition to the rather
> inappropriate, unjustified and offensive ad hominem that accompanies
> it.
>
> Lucio.
>
>> On 9/23/18, Robert Engels <reng...@ix.netcom.com> wrote:
>> Issues like these highlight the deficiencies of Go compared to Java. The
>> Java designers understood languages far better, and from the start realized
>> that identity and reference equality were different concepts. Everyone in Go
>> land are debating these solved issues. Pick and chose what you want to
>> implement but there doesn’t really need to be a debate on how to do it.
>>
>> Sent from my iPhone
>>
>>>> On Sep 22, 2018, at 8:52 PM, Ian Denhardt <i...@zenhack.net> wrote:
>>>>
>>>> On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
>>>>
>>>> I think the thing everyone who likes operator overloading like mainly
>>>> is being able to do infix and postfix syntax, instead of only prefix
>>>> (function).
>>>
>>> My own reason for wanting this is not really about syntax, so much as
>>> being able to define functions etc. which e.g. check for equality,
>>> without having to write too versions -- one that uses `==` and one
>>> that calls some method custom types. The syntax isn't really the point;
>>> there's an underlying notion of equality that we want to be able to talk
>>> about for more than just built-in types. We could define an interface
>>> for this:
>>>
>>> // The Equatable interface wraps the basic Equals method.
>>> //
>>> // x.Equals(y) tests whether x and y are "the same." The predicate
>>> // Equals should obey a few common sense rules:
>>> //
>>> // 1. It should be reflexive: x.Equals(x) should always return true
>>> // (for any x).
>>> // 2. It should be symmetric: x.Equals(y) should be the same as
>>> // y.Equals(x)
>>> // 3. It should be transitive: if x.Equals(y) and y.Equals(z), then
>>> // x.Equals(z).
>>> //
>>> // It generally does not make sense for a type to implement
>>> // Equatable where the type parameter T is something other than
>>> // itself.
>>> type Equatable(T) interface {
>>> Equals(T) bool
>>> }
>>>
>>> What I am suggesting is merely that `==` desugars to a use of this
>>> interface.
>>>
>>> An important litmus test for any operator we consider for overloading is
>>> whether we can come up with a clearly specified interface for it like
>>> the above. If not, it does not make sense to allow the operator to be
>>> overloaded, since it is not clear what overloaders should do. I believe
>>> this is the source of most of the problems with operator overloading in
>>> other languages.
>>>
>>> I think if we stick to this things will stay under control; there's
>>> currently nothing stopping folks from defining an instance of
>>> io.Writer that does something utterly in conflict with what is described
>>> in its documentation -- but that hasn't seemed to be a problem in
>>> practice.
>>>
>>> Quoting Michael Jones (2018-09-22 13:14:21)
>>>> the reason i wrote something like "...operator overloading, but wait,
>>>> don't get excited..." was to bring awareness of a core problem without
>>>> (hopefully) having people bring the burden of experience. i say burden
>>>> because bad experiences can shadow the 'why' that was good with the
>>>> 'how' that was bad. let the why foremost to "break these chains, rise
>>>> up, and move beyond" as in Callicles' famous speech.
>>>> the essential meaning of operator overloading and go interfaces and
>>>> Smalltalk messaging is a way to bind code to intent. (in general
>>>> intent
>>>> is named uniquely ("==") for simplicity but that is independent.)
>>>> Generics raise the need a way to say how the standard intentions play
>>>> out for our types. Imagine our gopher attired as a waiter, politely
>>>> asking questions of a custom type:
>>>>
>>>> gopher: Will you want to test for equality, madam?
>>>>
>>>> type: Yes, thank you.
>>>>
>>>> gopher: How would you prefer that test to be done?
>>>>
>>>> type: Hmm... I'll try 'IsEqualWithOddName(a, b *type)" for now.
>>>>
>>>> gopher: very good, madam.
>>>>
>>>> This mutual understanding needs to happen. how is open to discussion.
>>>> go interfaces use standard method names. operator overloading uses
>>>> standard symbols. macro expansion uses arguments. no matter how it
>>>> manifests, the power of generics relies on understanding related
>>>> parts.
>>>> we should talk about what kinds of parts deserve awareness.
>>>>
>>>> On Sat, Sep 22, 2018 at 8:46 AM Lucio <[1]lucio.d...@gmail.com> wrote:
>>>>
>>>
>>>>> It's good that you brought that up, because another issue I
>>> remember
>>>> from C++ V1.0 days, is that operator overloading did not allow for
>>>> changes in operator precedence, an arbitrary sop to some weird
>>>> decisions taken in earlier centuries. What I see as pertinent here, is
>>>> that precedence is yet another "type" property, this time not of the
>>>> arguments to an operator, but the operator itself.
>>>> As I pointed out in private correspondence to Ian Taylor, the entire
>>>> mess of arithmetic operations ought to be delegated to an APL-like
>>>> interpreter and all the complexities, of which being "generic"
>>>> functionality is not the only one, becomes one less problem for the Go
>>>> compiler. If APL is too obscenely obscure in the Go context, no doubt
>>>> there will be alternatives: it did not take Rob Pike long to produce
>>>> Ivy.
>>>> Of course, we also have indexing, indirection and a few other features
>>>> of Go whose role could be examined and formalised, perhaps more
>>>> successfully once the obscurity contributed by the arithmetic features
>>>> is expelled from the language.
>>>> Ian's response will remain with me for as long as I live, as I think
>>>> it
>>>> is very apt summary: that would not be Go. I entirely agree with him.
>>>> �
>>>>
>>>> But then also what do you do about interfaces that also implement an
>>>> operator interface? I'd guess biggest reason to not do it is�
>>>> 1) no human readable distinction between actual operations and one has
>>>> to decompose the code quite a lot as both types have to be known
>>>> before
>>>> you can attach it to an interface
>>>> 2) there is very few cases where being able to use infix operators
>>>> makes that much difference to readability, it's like you want some
>>>> mathematical notation but it's still all in lines. Chaining
>>>> pass-through methods works just as well and the types are much easier
>>>> to identify before you even fully parse it.
>>>>
>>>> Once we treat mathematical expressions as orthogonal to the language,
>>>> we get brand new choices, possibly opportunities: what is Boolean?
>>>> What
>>>> is a string that is not an array? Etc. A whole new chapter opens, for
>>>> better or for worse.
>>>> Lucio.
>>>>
>>>> --
>>>> 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 [2]golang-nuts+unsubscr...@googlegroups.com.
>>>> For more options, visit [3]https://groups.google.com/d/optout.
>>>>
>>>> --
>>>>
>>>> Michael T. Jones
>>>> [4]michael.jo...@gmail.com
>>>>
>>>> --
>>>> 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 [5]golang-nuts+unsubscr...@googlegroups.com.
>>>> For more options, visit [6]https://groups.google.com/d/optout.
>>>>
>>>> Verweise
>>>>
>>>> 1. mailto:lucio.d...@gmail.com
>>>> 2. mailto:golang-nuts+unsubscr...@googlegroups.com
>>>> 3. https://groups.google.com/d/optout
>>>> 4. mailto:michael.jo...@gmail.com
>>>> 5. mailto:golang-nuts+unsubscr...@googlegroups.com
>>>> 6. https://groups.google.com/d/optout
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>
>
> --
> Lucio De Re
> 2 Piet Retief St
> Kestell (Eastern Free State)
> 9860 South Africa
>
> Ph.: +27 58 653 1433
> Cell: +27 83 251 5824
> FAX: +27 58 653 1435
--
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.
For more options, visit https://groups.google.com/d/optout.
