Those are good points and FWIW I would be excited to use the proposed indexing functions and agree that they are a big part of the issue, independent of the operator overloading. There has been a lot of discussion about supporting multidimensional indexing etc so this has been a major issue over the years, so maybe this will go forward!
- Randy > On Oct 8, 2020, at 2:18 AM, Raanan Hadar <rha...@gmail.com> wrote: > > So the first paragraph in my answer to Jon addresses this. But I think I > could have been clearer: I think 80% of the readability problem is addressed > by index operator methods, which is the critical part. Full operator > overloading is nice to have in my opinion and I argue people will gladly live > without it given all the other benefits Go brings to the table in software > engineering. I think its a very similar approach to what Go did with > pointers: Is full pointer arithmetic beneficial? yes, but it would no longer > be in the spirit of Go. > > I think that using languages such as Matlab and Python as a starting point, > or "prototyping languages" is becoming less and less relevant today. This > might have been the way we developed algorithms ten years ago but today its > just like any software development. The reality many data scientists and > engineers face today is that data pipelines are constantly changing and > increasing in complexity. They need to be maintainable and allow for quick > iteration, integration and deployment. These are the qualities that Go excels > at. A language that can effectively achieve a prototype in 80% the syntax > efficiency but can sustain quality over time is much more important than > having the richest syntax possible. Another point is that even while in the > "prototyping" phase, big data challenges which data scientist face today, > unlike ten years ago, will require the data scientist to do some heavy > lifting to get efficient compute, network and IO to get that initial result. > So in many cases the "prototype" is often a complex pipeline that is deployed > in k8s for example. > > I think that a Go-Python integration is excellent but as I noted, it leaves a > lot to be desired. A lot has been written about the "infinite loop of > sadness" (here is a good link: > https://medium.com/pachyderm-data/sustainable-machine-learning-workflows-8c617dd5506d). > I think this is a big problem with companies like Google having an excellent > understanding of challenges of sustaining data pipelines at scale. Its a lot > of what they do in their day to day. This is why, I think the synergy in a > single language will be amazing. > > As for Julia, I was also excited when I first learned about it and I hope I > am not offending anyone using Julia here. Because on paper its marketed as > the killer language for this, but Julia has two big problems (I sample Julia > regularly): > 1. Julia is nowhere near ready. Julia has a few more years before it gets its > basics down. I think it has made a lot of progress in the last few years but > someone trying Julia out in 2020 is guaranteed to hit some really annoying > hurdles from day one. I'll give you a trivial example, lets say you want an > IDE for Julia. Your best bet today is probably a text editor like vim or > emacs. You have JUNO for atom which is nice but no longer developed or the > vscode IDE, which might be amazing in a few years but is far from stable > (https://github.com/julia-vscode/julia-vscode/issues). And this is just one > critical issue out of many. > 2. My second issue with Julia is more troublesome because unlike the first, I > don't think it will ever be solved. Julia is a language that was designed to > be very rich syntax and feature wise. But its toolchain was completely > neglected. Go has an amazing toolchain, its not the sexiest part of the > language, but its critical and it was designed to encourage good software > engineering. As Rob Pike said: "Although tools like these are rarely > mentioned in the context of language design, they are an integral part of a > language's ecosystem and the fact that Go was designed with tooling in mind > has a huge effect on the development of the language, its libraries, and its > community". Julia has poor package management and tooling which make it a > pain to deploy in production compared to Go. > > In summary, If Go were to implement this, I really believe that it will run > circles around Julia even in a few years from now when it reaches puberty. > Because Go is a better language when it comes to software engineering. > On Thursday, October 8, 2020 at 7:46:16 AM UTC+3 rcore...@gmail.com wrote: > I think we all agree that Python has some major issues.. :) > > But the point of Jon's argument which struck me as very compelling is that Go > would really need full operator overloading to serve as a serious competitor > given the standards to which people have become accustomed. I didn't see in > your replies a clear response to that, but maybe I missed it? > > The really tricky issue is that everyone wants something like Python *as a > starting point* when just messing around, because it is so easy and flexible > to just write simple expressions etc. But then once things start to scale up, > all the "issues" start to outweigh those initial advantages. And for a huge > number of Python users, they never scale up and don't care about anything > more than getting their immediate needs solved, mostly by copy / paste / > modify programming.. > > That's why I think the Python / Go hybrid approach could be good -- end-user > type people can mess around in Python, but the same functionality is > available in Go, and as stuff starts to get scaled up to the point of > requiring more libraries, those can hopefully be done in Go, so that Python > always remains on the "messing around" scale of things, while the deeper > infrastructure gets built out in Go.. This probably requires a fair bit of > extra work and motivation on the part of the Go-side developers to keep up > with things and support the developing needs of their users, so it may not be > plausible for a larger-scale community, but it is working pretty well for my > small-scale biological neural network modeling community.. > > Functionally, it is sort of similar to having a transpiler, in that Python is > just providing a simple front-end syntax for accessing the deeper Go > functionality. > > Anyway, wasn't Julia supposed to solve all these issues? I don't know much > about it in detail, but I googled just to see what the latest discussion > there is relative to Python -- this thread is informative and current: > > https://discourse.julialang.org/t/why-is-python-not-julia-still-used-for-most-state-of-the-art-ai-research/45896/17 > > > The basic thrust is that people don't care and just go with what everyone > else is doing. This was the best quote IMO: > > > There are countries that still do not use the metric system, you figure it > > out. > > Also this is informative: > > > For my subjective idea I would also say Python, as someone mentioned here, > > is much easier language than Julia. Coming from MATLAB looking at packages > > of Julia seems to me as an act of wizard. > > Python hits a sweet spot of simplicity and power.. Julia apparently does not. > Go hits a different such sweet spot, but not with the same kind of > transparent syntactic expressions needed for data science / ML etc. > > - Randy > > > On Oct 7, 2020, at 5:49 PM, Raanan Hadar <rha...@gmail.com> wrote: > > > > So we respectfully disagree here, so the best thing I can do is add some > > quality arguments. I think this is an important discussion that might > > cement Go as a broad DSL in the sense that it does a lot of things > > exceptionally well, but this issue will remain a blind spot. > > > > I fully understand the need to keep Go "pure and simple". Its the key to > > its success. But this is an important area where Go does not have enough > > features to be effective. Secondly, I think that solving this issue can be > > achieved while maintaining orthogonality and not hurting experience of the > > majority. Third, as I answered Jon, I think that looking at this proposal, > > or more generally, this problem, from the Go programmer's perspective, is > > like trying to optimize a local optima. Go programmers don't have much to > > gain from this. But from a global perspective that seeks to optimize > > software development as a whole, there's a huge benefit that is overlooked > > here. Go was not designed to cater the needs of the programmer but software > > engineering as an end to end process > > (https://talks.golang.org/2012/splash.article). > > > > With regards to Python, I've detailed common examples in my proposal, where > > Python for numerical computing leaves a lot to be desired. Fundamental > > issues which Go solves by design and are not addressed effectively by > > putting the two together as you suggested. Secondly, I am not the only one > > saying that there is a real need for a better language than Python. To name > > two good examples: Yann LeCun said this last year: > > https://venturebeat.com/2019/02/18/facebooks-chief-ai-scientist-deep-learning-may-need-a-new-programming-language/ > > and Jeremy Howard, former president and chief scientist of Kaggle and the > > author of the fast.ai, strongly advocates that Python is not the way to go > > in long run: https://www.youtube.com/watch?v=c-KAf2g6YN4 > > > > > > On Thursday, October 8, 2020 at 1:10:22 AM UTC+3 rcore...@gmail.com wrote: > > Jon's points probably sink this proposal. Go is a very different language, > > and making it less self-consistent to solve some fraction of syntactic > > readability is almost certainly not going to get over the very high > > threshold for changing the language. > > > > If you're going to switch over to Go, you'll have to learn a LOT of new > > concepts and change the way you approach things. In the end, it is better > > that Go remain "pure and simple" -- the simpler it remains, the easier it > > is for anyone to learn it, no matter where they are coming from. > > > > Another strategy, which I'm pursuing, is to support Python as a scripting > > language on top of Go backend code that does all the heavy lifting. That is > > how Python is used in most cases already, except with C / C++ backends. So, > > keep Python Python, and keep Go Go, but allow people to interoperate more > > easily. This way, people can get some exposure to the virtues of Go, and > > maybe decide to switch over at some point.. > > > > This tool makes it relatively easy: https://github.com/go-python/gopy I've > > also written a GoToPy converter https://github.com/goki/gotopy (will be > > moving over to go-python soon -- no time right now), so you can write > > 'main' programs in Go, then easily convert them over to Python (Go -> > > Python is very easy, the other way not so much), which provides a point of > > departure for Python folks to start using your code.. > > > > - Randy > > > > > On Oct 6, 2020, at 12:56 AM, Raanan Hadar <rha...@gmail.com> wrote: > > > > > > 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. > > > > > > > > > -- > > > 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/ee94ef0a-c461-4262-99fe-25a52ee11646n%40googlegroups.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...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/golang-nuts/c475d7e6-3724-409d-9532-6b933b67cf2dn%40googlegroups.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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/82947d3c-e7ad-4f3b-8358-50d6809c040fn%40googlegroups.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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/DECB18FD-D873-421A-AF2C-AB18AFD99BC9%40gmail.com.
