You did not offend me. This is a place for earnest ideas and all are
welcome.
Your comment is not yet persuasive, but it might become so. Still thinking.
I first heard from James Gosling about Java when Java was Oak. He seemed
proud to say, "C++ has objects. Well, I'll show them, I'll make *everything*
objects!" That they did. I've been recalling those days and wondering if
that team knew more about language design in some privileged way or was
just turning the knob to eleven. Still not sure.
I am sure that Alan Kay et al had important, fundamental insights in
Smalltalk. Variables had named attributes and they could be inspected in
code and visually with an inspector. I could ask you about your type, size,
length, etc. If i asked an inapplicable question i got a survivable answer,
not a panic. I raised this pre-Go1 in Google with the idea of, why are
Len() and Cap() not implicit methods on a slice? I like that because it
also suggests asking a variable, "hey, what is your minimum expressible
value?" in a way that is type agnostic. Being able to as parameter t of
generic type T a question like "x := t.MinExpressibleValue()" has a grand
flexibility compared to a type switch that then knows about library
functions for math.MinFloat64(). There were reasons why not, but in this
quest I'm not persuaded against the notion that *every common attribute of
T should be knowable from t, an instance of that type*. In Go this happens
with magic compiler generics (len(x), cap(x), ...) that take any and all
types and do the right thing. I'm more a fan of no magic and a simple
universal notion that applies to every type, built-in or custom.
In this sense, the Java team's gusto and my deep respect for Smalltalk's "a
queryable database of instances" (aka, DOM decades before) align and I do
like that path.
On Sun, Sep 23, 2018 at 9:17 AM Robert Engels <reng...@ix.netcom.com> wrote:
> 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
>
>
--
*Michael T. jonesmichael.jo...@gmail.com <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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
