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.
Wolfram Mathematica has an overloading approach which also has pattern matching... it simply fits very well to a symbolic CAS. > > 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. > > 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. When Python was invented it was an extremely difficult task to write such a thing, both a compiler and an interpreted language, because you had to write it all on your own. Today we have LLVM, which is of great help, and LLVM is a recently appeared tool. By the way, Julia-Python interaction is already there. As Julia is able to compile to machine code, it should be easy to extend the LLVM compiling framework to create compiled Python plugins, but I don't know what's in the developers' minds. In any case I read that some of cython's developers are amazed by Julia. > > 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. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
