Thomas, Good morning old friend. Yes the implementation of axiomized arithmetic has proven difficult. Not that it is too hard, but because (I think) it requires a mindset alien to most developers. It works very well in the symbolic algebra system Axiom which is the acme; A matrix is not just "a matrix" but a 2D "matrix of integers taken from a specified field." The precision and clarity are high and the thinking required to state just what things are is also high. This works here, and pretty well in Mathematica, but really has no counterpart in computer arithmetic where even addition may violate the rules of mathematics.
It would be nice to say that a Complex() or Quaternion() was a tuple of Numbers() and have it be true that fully performant big float complex math could be expressed that way, Very nice indeed. Something I look at,. But, it seems ambitious and suggests that built-in complex types still have a home. I believe average Go code will be better if there are map-quality llrb trees, stacks, sets, ... for the taking, just as if tuples were a first class thing. There were horrors in STL's evolution, but by now, everyone gets such data structures right the first time they use them, just as they do now with Go maps. Michael On Tue, Sep 18, 2018 at 11:53 AM <alan.f...@gmail.com> wrote: > Eric, > > This is the sort of situation where a tool could help. > > If the tool detects that you've written a generic type/function but only > then instantiated it once, that could lead you to rewrite the type/function > non-generically for the type(s) actually used in the instantiation. > > Alan > > On Tuesday, September 18, 2018 at 6:38:34 PM UTC+1, Eric Johnson wrote: >> >> >> >> On Tue, Sep 18, 2018 at 6:21 AM Robert Engels <ren...@ix.netcom.com> >> wrote: >> >>> I am going to refer everyone involved in this discussion on generics to >>> this once again. I know it is long, read the summary... but it’s important: >>> >>> >>> https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics >>> >> >> I'm skimming that paper. Thanks for sharing. Paper definitely identifies >> benefits for adding generics. >> >> This quote jumped out at me for its relevance to this discussion: >> "We observed parameterization of 1152 types, but actually found about 46 >> % of these types (532) only had exactly one type argument ever used >> throughout the project’s history, suggesting that needless or premature >> generification of objects occurs fairly frequently.We observed >> parameterization of 1152 types, but actually found about 46 % of these >> types (532) only had exactly one type argument ever used throughout the >> project’s history, suggesting that needless or premature generification of >> objects occurs fairly frequently." >> >> Put in the term of this discussion thread, the study notes that about 45% >> of the time (for the Java projects studied), portions of the code get >> harder to read, with little or no clear benefit. There's no basis for >> thinking that the same problems will or won't occur with any generics added >> to Go, but it seems like a reasonable place to point to for concerns >> driving this thread. >> >> Eric. >> >> >>> >>> On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki <oh...@fairbe.org> >>> wrote: >>> >>> On Tue, 18 Sep 2018 04:38:55 -0700 (PDT) >>> ffm...@web.de wrote: >>> >>> Every average Joe Java boilerplate coder gets along with generics. >>> >>> Barely, if at all, understanding whats under. >>> >>> "Smart Copy Paste ... A book for normal programmers" >>> >>> https://www.amazon.com/Smart-Paste-Stack-Overflow-other-ebook/dp/B01EHI5RQM >>> >>> But even there you can manage without thinking and just doing >>> >>> trial and error if you wanted to. >>> >>> >>> OP, I and many others want to defend Gol off this very attitude. >>> Go is among few contemporary languages that allows me to fully >>> understand what my resulting binary will do, down to the syscall >>> level. Thats precious. >>> >>> >>> I think it will neither be tricky to make use of nor to read the code. >>> >>> >>> I claim opposite. All and any Gopher will be expected to cope with hard >>> to >>> read and yet harder to understand generic code. Even if she herself will >>> vowed not to use it. In a short while we all will be obeying first Java's >>> commandment "thou shalt not peek under". >>> >>> >>> -- >>> Wojciech S. Czarnecki >>> << ^oo^ >> OHIR-RIPE >>> >>> -- >>> 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...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "golang-nuts" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/golang-nuts/3ia8XrUgqOg/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> golang-nuts...@googlegroups.com. >>> For more options, visit 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. > -- *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.
