> Just a suggestion: if you want to improve the speed of symbolic >> mathematics as done by Maxima, and you are no longer insisting on the use >> of Python, why not write in Lisp, and make Maxima faster? > > > oh well - anyway, it is fun to watch C/C++ programmers discovering the > wrath of > https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule > >> >> More seriously perhaps, "Python wrappers allow easy usage from Python and integration with SymPy <http://sympy.org/> and Sage <http://www.sagemath.org/> (the symengine.py <https://github.com/symengine/symengine.py> repository)" which probably is not the case even with our use of Maxima as library.
As for the substance of Richard's remark, the truth is that at least to some extent one has to go with supply, not just demand: https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/ and while I'm not sure that "HTML/CSS" is Turing-complete, at any rate if this graphic is even remotely accurate there simply aren't enough people who know Lisp (or even Scheme or Clojure or ...) well to focus on it within a scientific ecosystem already dominated by things like Python and R. That is too bad, because if we had had that competence early in the project, I could have imagined a lot of energy on improving Maxima; but time considerations have to be part of it too, not just technical considerations of which language is "best". As to the question of replacing backends, there is already a ticket (which I cannot find right now, my apologies) which started the process of seeing what doctests would fail if we went to Sympy as default. Presumably something similar could be done with this engine (I don't know if it is more for low-level symbolics or also things like integration). However, one of the strengths of Sage is that one can check computations using several backends at a time, including with optional things like fricas (still?), and likely Maxima will still prove to be better at certain kinds of computations, so improving Maxima will still help Sage's capabilities no matter what happens. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/948f5e87-8de2-4003-b85b-baf0f33c4439n%40googlegroups.com.
