(Some unjustifiable opinionated ramblings from a faraway place, read at your peril.)
It took Dijkstra quite some effort to accept the concept of "interrupts" (quotation anyone?), but eventually he went with it. Resistance to operator overloading is as admirable as it is futile. Ultimately, the range of base types in a programming language is an arbitrary decision and the operators applied to them is equally an artifact, not divine inspiration. Go slipped badly when it added "+" as the string concatenation operator and I don't remember much resistance to that. In fact, I have adopted the expression x += 1 in lieu of x++ in all my coding specifically because I don't think the increment operator is necessary at all; a circular shift operator has more merit, but no one asks for that. Nor has anyone, including Rob Pike, suggested that we head the APL route and add any available special symbols as operators. I can see why, of course! I would expect programming languages one or two generations from now to resemble nature more closely and allow programs to evolve rather than be "written" or coded. For that, the basic building blocks have to change dramatically. But our guidance may well come from the DNA double helix and its very small range of components. I find generics inelegant, they lack any aesthetic appeal and that was enough for templates to turn me off C++ 2.0, I hope that Go will not adopt similar ugliness. That said, if one could treat types as mutable properties of the language objects (variables that can be transformed between "compatible" types - a lot like interfaces allow presently, but much more visibly, perhaps, I haven't thought that hard about it), then "generic functions" would span such "types" intrinsically and still protect the program from mistakes at compile time. Hmm, if the type assertion was intrinsic rather than explicit, perhaps? We're trying to avoid that, so we need a concept as fresh as "type interface", but more amenable to enumeration, an explicit "type set" perhaps? I seem to remember something like that from "kencc"? Ultimately, to return to the topic of operator overloading, with C++ they came before templates and templates were the inevitable progression. Interfaces are a different starting point and there is no immediately obvious progression from there, but maybe the Go "leading minds" haven't been looking. Maybe all we lack is the type of theory that went into describing SQL as a mathematical concept, applied to interfaces, just maybe... A final thought: the Go.1 promise is a wonderful idea, since it encouraged a whole cultural group to look for every conceivable improvement that could be made to a very stable core. But of course it had to apply blinkers. Eventually, someone will peek over the edge of such blinkers and figure what we've all been missing. It is not a critical component, but once it or they are identified, it will be hard to imagine how they could have been missed for so long. Lucio. On Saturday, 5 August 2017 03:52:28 UTC+2, as....@gmail.com wrote: > > I'm hesitant to accept generics due to the fear of *overloaded operators > *being > the next big deal*. *C# even has *properties (user-defined methods > dispatched upon an assignment operation)*. > -- 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.
