On Thursday, 21 August 2014 23:08:18 UTC+2, Dima Pasechnik wrote: > > On 2014-08-21, Bill Hart <goodwi...@googlemail.com <javascript:>> wrote: > > ------=_Part_5_2037022158.1408650350021 > > Content-Type: text/plain; charset=UTF-8 > > > > Julia can already call Python functions (and I don't mean in some > > theoretical, technical sense, I mean very practically via an interface > > designed explicitly for such). So it's not necessary to "move" Sage from > > Python to Julia. Other Scientific Python projects haven't done this. > > > > There are other reasons why this is not necessary, because of other > > technical advances that will become available in the coming few years > (they > > are working in labs right now). > > > > Instead, the Sage project should do two things in my opinion: > > > > 1) Make Julia part of the Sage ecosystem (it's already had a huge > > investment from the scientific and statistical communities, so this is a > > no-brainer if you want to embrace that community) > > > > 2) Invest in the technologies that are making Julia successful (jit, > > dependent typing, metaprogramming, type checking and inference, etc.) > > > > Whether 2 involves rewriting some functionality in Julia, or simply > finding > > ways of adding such functionality to Python is really neither here nor > > there. > > > > What Sage can't do is just stagnate and ignore progress. If it does, it > > will be brushed aside as if it wasn't even there, as has happened over > and > > over again in the history of computer algebra! And it's happening to > Sage. > > A few years ago, people at conferences were excitedly demonstrating > stuff > > in Sage. This year, they've moved back to Magma. > > Perhaps, it's merely thanks to Simons Foundation making Magma free for all > universities in USA? >
Definitely a factor. But a minor one. William is pretty much right about why people are going back to Magma. But a lot of people are missing the other reasons.... > > Oh, perhaps you mean that Magma has switched over to Julia? :-) > Noooo. Julia is not the issue here. I honestly couldn't give a toss about Julia. I've been very open about the fact that I think there are things wrong with Julia and that I will likely move my work from Julia to some other language in the future (when such a language becomes available). But it is definitely the best language around for this sort of thing. The issue here is the technology Julia is based on. Without it, you are going to very rapidly fall behind. And I said so very publicly, years before Julia was even announced (I'd have to check, but possibly even before private development of Julia began). At the time my "criticism" was posted to sage-flame and ridiculed. Anyway, to address your point. Magma is technologically superior to Sage in many ways (and in other ways is completely backward). Magma has been actively investing in parallel and GPU technology. And I happen to know they employed at least one person working on LLVM and web-based technologies. Magma has its own language, and doesn't need Julia. They can (just as Sage can), embrace the new technological innovations, without throwing away everything they have. Magma isn't a static target for which development stopped when Sage began. It is a moving target, that in some areas will always outstrip Sage. The only way to beat it, is to make sure Sage can move even faster than they can in embracing new technology. It needs to be possible to get a Magma beating solution off the ground in half the time Magma can do it. And that is nowhere near the case. > > > > > As I have already mentioned, the technology behind Julia can in theory > do > > generic programming even faster than C or C++. So it is a strictly > superior > > technology to what has been available in the past. It's a genuine > > innovation, whether the Julia designers see it that way or not. > > Wait, are you saying there is an optimising Julia compiler available? > You don't need an optimising compiler for Julia. Precisely the same backend that is used for the Clang C/C++ compiler underlies Julia. It's over 1 million lines of code. The difference is, it is jit compiled. > Without it, it sounds a bit like claims by Java poeple saying that their > JIT compilers are so great that they beat C compiled with gcc... > No, I said generic programming can be faster in Julia than in C. Not that generic programming can be faster than some particular C compiler. The technology is fundamentally superior to C. That's a concept people are going to take a long time to understand and accept, but it's true. In theory, I can do generic programming in Julia that is faster (at runtime) than you can do in *any* C compiler. And I don't just mean a little bit. I mean a lot. I don't even think the Julia people fully realise this yet (I might be wrong about that, I don't know). And it's not been realised in practice for many cases. But it is true. On the other hand, because the Julia Jit is based on the technology behind Clang, it can sometimes outperform gcc, just because Clang can. GCC isn't working on their own Jit technology for nothing! The point is, Julia has a massive optimising compiler behind it. People don't realise this. LLVM is NOT a virtual machine, nor is it a peephole optimiser. It is an optimising compiler. It performs most of the optimisations *at the back end* that would normally be done by the compiler *front end*, because it carries "rich type information" right through. Type erasure still occurs at execution time, obviously. But LLVM can optimise what would otherwise be done by the front end of a compiler because it retains enough semantic information to do so. And LLVM can be used to automatically optimise any program language that uses it for GPU's and, and, and. However, none of that is what I am referring to. I'm referring to Julia's ability to do zero cost abstractions, meta programming all on top of a Jit. You cannot do any of those things in C. It's strictly more powerful. My cursory look into Julia only poped out JIT stuff, not a real complier... > Static compilation is coming to Julia. But not because it will speed things up. It already has all the speed of an optimising compiler at the console, as you type! > > > > The Julia developers are not like me. They like Python and embrace it > (many > > of them are pythonistas). They would never go around claiming Julia is > in > > any way superior to Python. But I am not one of them and can go around > > making such claims, because in the sense that I mean it, it is true. > > What personally put me off Julia when it was announced was that > "We are power Matlab users" in the top of the blog post announcing > Julia project back in Feb 2012. I thought "oh yes, swell, we do need a > better > Matlab nchoosek() and 'everything is a matrix' greatness :-)"... > They actually wanted to be the next R. But lots of Matlab users saw potential. In my opinion, Julia is Ma* agnostic. They have a heavy bias towards numerical stuff at present, and they need an algebraic stack. But I'm having no problem writing one. You can literally load Julia in bare-module mode. It throws all the numeric stuff in the toilet, and you can define your own semantics on top of Julia. Kind of like the prelude in Haskell. This needs to be done by some serious algebraists. But it's not hard work. > > Dima > > > > > Bill. > > > > On Thursday, 21 August 2014 20:33:00 UTC+2, mmarco wrote: > >> > >> So, would it be thinkable of to move sage from Python to Julia? Sounds > >> like a titanic task, but sounds like if there are so many advantages in > >> Julia with respect to Python, it could be worth it. > >> > > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
