Lets start with saying that I think this is a valid criticism. Although it does not solve things 100%, it does solve the heart of the problem for me at least: There is a mixture of index operators with functional operators in the syntax: The [] operator gives the reader the 'where' context and the () gives the reader the 'what' context. If you are using all your arguments via () causes the readability problem. So while not having full operator overloading, you still have to use .Add() instead of '+', the grammar is now consistent and concise and separates the 'where' from the 'what'.
Also, please consider that different users have a different 'value scale' to gain from this proposal: To a gonum user, this proposal is about a 20% improvement and nothing to run home about. To a matlab/python programmer, this solves about 80% of their problems and combining this with the other benefits of Go is enough to strongly consider switching to Go. Realistically, I don't think that I can convince the Go core dev team to add full operator overloading and that is probably the only way to achieve what you are suggesting... if you have another way to achieve this, I am open In the end of the day, the question to ask is whether or not we are better off in implementing this. On Tuesday, October 6, 2020 at 9:33:17 AM UTC+3 jonr...@gmail.com wrote: > i think this looks nice but realistically only cleans up v simple cases. > a lot of the very-verbose-and-not-so-elegant-looking multidimensional math > stuff looks "worse" than other languages because go doesn't have operator > overloading. it is not clear to me this improves syntax too much in > practice on it's own. (this is not a request to add operator overloading > but merely the non-controversial statement that operator overloading can > help math-heavy code look more "hand drawn" sometimes). > > the gorgonia example is indicative of the issue: nil may be less > aesthetically pleasing than ":" (or not) but it's unlikely the surrounding > code looks anything like the math as expressed on paper by hand either. > > gonum is quite convenient even with this...code that uses it can look a > bit more 1960s than other languages but it is simple and super-clear. i > like that i am never (read: rarely) confused by () or , or [] etc > characters in go. if you could find a way to cover more ground the change > would look more compelling to me. > > On Mon, Oct 5, 2020 at 12:04 PM Raanan Hadar <rha...@gmail.com> wrote: > >> It actually didn't change that much, I just applied your valuable >> feedback. Thanks alot! >> >> Its critical to communicate clearly. >> so I changed the before and after part of the proposal to be more >> approachable to people who >> are less familiar with numerical libraries in Go. >> >> Its not a trivial proposal in that the main audience will probably use it >> in a library and not in vanilla Go. >> But it was still a very valid point. >> >> thanks again. >> >> On Monday, October 5, 2020 at 3:19:02 AM UTC+3 jake...@gmail.com wrote: >> >>> The examples I was looking at are gone now. That section has been >>> completely rewritten. So its kind of moot. Its possible that I was >>> confusing the 'before' and 'after' examples, since they were not clearly >>> labeled. In any case the rewritten version seems to make sense now. >>> >>> On Sunday, October 4, 2020 at 4:50:10 PM UTC-4 kortschak wrote: >>> >>>> On Sun, 2020-10-04 at 09:06 -0700, jake...@gmail.com wrote: >>>> > I stopped reading at the " Show example code before and after the >>>> > change " because many of the examples of "before the change" code >>>> > seem to be invalid in go, and the others do not do what you seem to >>>> > imply they do. Am I misinterpreting this section in some way? >>>> > >>>> >>>> I'm curious as to which examples of "before the change" you think are >>>> invalid. From what I can see there, one is borderline (in the last >>>> example there is no package selector, but it could have been a dot >>>> import and is likely this way for brevity). The rest look like normal >>>> method invocations, which are the standard way for this kind of thing >>>> to be done in the current implementations of matrix and tensor >>>> operations in Go. >>>> >>>> Dan >>>> >>>> >>>> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/f49975aa-5a76-45b7-a158-b1067b1dc580n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/f49975aa-5a76-45b7-a158-b1067b1dc580n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ee94ef0a-c461-4262-99fe-25a52ee11646n%40googlegroups.com.
