For a long time, I've been complaining about the interface between Maxima and Sage. It doesn't just make calculus slow, it slows everything down -- every time I take a logarithm or a square root in a numerical algorithm, Maxima slows me down. I now realize that the right solution has just been staring me in the eye for the entire time! Maxima wasn't the problem -- Python was! If we were able to call Maxima functions directly, this bottleneck would just vanish. Perhaps we should have been listening to RJF all along -- perhaps our core should not be lisp, but Maxima. In the rare instance where Maxima isn't the fastest way to implement things, then we could certainly do some more radical optimization in lisp.
I'd never have believed I'd say this... but let's do it! I support this 100%! Jason -- I think that Lispy is a better name than Lython. Lython sounds so... dishonest. But I'd much rather see a Python-to-Lisp compiler than a Python interpreter. That should make our migration procedure much faster -- maybe we could get 'er done by next year! On Wed, Apr 1, 2009 at 10:59 AM, William Stein <wst...@gmail.com> wrote: > > Hi, > > About two years ago we made the painful transition from using Darcs to > Mercurial for our revision control system. This was difficult, but had > to be done because it was hard to get Darcs to run everywhere, and > there were weird corner cases where Darcs would hang. Mercurial isn't > optimal but it gets the job done. > > Frankly, I think we have similar problems using Python at the core of > Sage. I've been thinking very hard about how to deal with this for > nearly a year now, and have come to the conclusion that we should make > a switch from using Python at the core of Sage to Lisp. The > transition won't be easy, but it will be well worth the effort, since > in the time frame I have in mind (30 years, say) I see Lisp really > taking off, and despite its faults, anyone who has used Lisp a lot > knows that Lisp is clearly a far better language than Python in > several critical ways. The strategy for switching will go something > like this: > > 1. Forking: We fork clisp. We have been using clisp for several > years now in Sage, so we're very familiar with their build system. > However, they don't make regular releases, and their foreign function > interface is severely lacking, as is their Solaris support. So we're > forking, and will call the fork LispX. I've talked with Robert > Bradshaw about creating a new language called CylispX, which will be > similar to Cython but for LispX, and I'm confident we can pull this > off. > > 2. Porting: We have an intense sequence if "Lisp days", both > workshops and 1-day long IRC events, where we go line-by-line through > the Sage library and rewrite everything in Lisp. As we go, we'll > make sure that the rewritten code is always at least as fast as the > original code (this shouldn't be a problem, because of LispX's > extremely good profiling and dynamic optimization features). I hope > everyone here is willing to pitch in significant time to this effort. > If you're not, I would really like to know what your concerns are. > > 3. Polish: I estimate step 2 will take about 3 years, given the > amount of time it took to write the original Sage library, and also > the level of familiarity of most Sage developers with Lisp. Also, we > will likely run into subtle snags with SageLisp's interface for > calling C functions. But with everybody's hard work, we'll get > through this. > > 4. Sage-4.0: On April 1, 2012, we'll release Sage-4.0, which will be > the complete Lisp-rewritten version of Sage. We will then get to work > on porting all of the nasty C/C++/Fortran dependencies in Sage to > Lisp. We'll likely start with GMP/MPIR (we may have to fork, though I > *hope* Bill Hart will be on board), then moving onto mpfr, mpfi, > FLINT, PARI, etc. I estimate that with lots of hard work by everybody > reading this email, we can accomplish this in at most 4 years. This > will be a great contribution to mankind. > > 5. Finally, on April 1, 2016, we'll release Sage-5.0, the fully > Lisp-ified Sage. We will then get back to porting Sage to Windows, > Solaris, and implementing new functionality for combinatorics, linear > algebra, number theory, algebraic geometry, optimization, etc. > > If anybody isn't 100% convinced that this change isn't -- in the long > run (30 years) -- well worth our effort, please respond. > > -- Best Regards, > William Stein > > -- > William Stein > Associate Professor of Mathematics > University of Washington > http://wstein.org > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
