On Mon, Oct 7, 2013 at 2:09 PM, Joachim Durchholz <j...@durchholz.org> wrote: > Am 07.10.2013 21:06, schrieb F. B.: >> >> >> >> On Monday, October 7, 2013 8:28:04 PM UTC+2, Joachim Durchholz wrote: >>> >>> >>> Am 07.10.2013 20:07, schrieb F. B.: >>>> >>>> I just had a look at the Julia project http://julialang.org/ >>>> >>>> Have a look at how they manage operator overloading: >>> >>> >>> I just did and shuddered. >>> Unrestrained multple dispatch runs into modularity issues. It's one of >>> those mistakes that language designers make over and over again, because >>> the base idea seems to simple and the use cases one can think of are so >>> straightforward, but they almost never consider the case what happens >>> when two independent developers have their work merged by a third. >>> >>> >> Methods and operators in Python and C++ are not very different from >> Julia's >> idea, it's just the way you write it: the first argument in Python is >> *self*, >> >> you just have to write it inside the class declaration, while in Julia you >> write it outside of it. The same is true for C++ methods, the only >> difference is that in Julia you're free to write the methods everywhere, >> but problems could be avoided by keeping the code clean. > > > The relevant point is that you have multipe parameters that you dispatch on > (or overload, the issues are the same). > > >>>> That is a great idea, it would keep code clear and readable, and avoid >>> >>> the >>>> >>>> need of all those *if isinstance( ) ... elif isinstance( )* >>> >>> >>> There are better and more general ways to avoid that. >>> Unfortunately, neither Julia's approach nor the ones typically employed >>> in FPLs are available in Python. >>> >> A type dispatcher is a must for a CAS, in my opinion. It would keep things >> easier. > > > Yes, but multiple dispatch is *so* not the way to go. > Unless all dispatch combinations are forced to be within the same module. > > Multiple dispatch: modularity, unsurprising behaviour, unrestricted ability > to add new variants - pick any two. > > >>>> By the way, the aim of Julia is to be both an interpreted language and a >>>> fast compiled language, with speed of execution near to those of C. At >>> >>> the >>>> >>>> same time they want to keep perfect interaction with both Python and >>> >>> C... >>> >>> Sounds like they're too ambitious to succeed. >> >> >> Well, it is not impossible nowadays. There is LLVM now. > > > LLVM solves quite a few challenges, but not these. > > >>> > and at the >>>> >>>> same time allow perfect interaction with both Python and C, and reach >>> >>> the >>>> >>>> performance of C. >>> >>> >>> I doubt that you can have both easy interaction with dynamic languages >>> and raw performance. To the very least, you'll have to keep the number >>> of inter-language calls down, and that would impose design restrictions >>> on Sympy's code. Sympy already has a lot of restrictions to observe, I >>> doubt that that's going to be easy. >> >> >> Well, I believe that you are looking back in time at traditional >> languages, >> without realizing the power of a language specifically engineered for >> scientific research. > > > I think I should stop in politeness here and just point out that you are > wrong in your belief.
Let's keep being polite please. :) I have similar views as F.B., so I won't repeat them. But I would point out, that besides Julia, there is also Numba, with similar goals --- they started optimizing arrays, but my understanding is that they plan to ultimately allow more things, similar to Julia. My ultimate conclusion is, that it remains to be seen, in a few years, how well these new languages perform. While C++ and Fortran allow me to have very high performance now. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
