3 ms·

First of all, thank you for all of your hard work. One thing I am curious about though is how you think you can match the "cohesiveness" of Mathematica. While I

First of all, thank you for all of your hard work. One thing I am curious about though is how you think you can match the "cohesiveness" of Mathematica. While I am not a big fan of Mathematica the language, there is something gained by a top down approach. The options all seem to have the same names, the display tools tend to compose with new functionality well, the symbolic parts integrate well with the numerical tooling. While the poly-sourcing approach of Sage can definitely excel in the features area (and definitely surpass it in more "esoteric" areas of algebra), I do think that the tools end up with a higher barrier to entry since it's much harder to police syntactic and dependency inconsistencies. I am trying to work out some of these problems of my own and was wondering how you're coping with it.

williamstein 9y ago
> how you think you can match the "cohesiveness" of Mathematica The basic strategy is to provide a new Python library ("the sage library" [1]), which is a layer between the user and the other dependencies. E.g., instead of just saying "use Maxima for symbolic limits", we have our own notion of symbolic functions (implemented using Ginac), and automatically convert them to and from Maxima when doing symbolic limits. The user never has to know anything about Maxima. When we first implemented this, it just used interprocess communication under the hood, but (thanks to Nils Bruin and others) we now use a direct C library interface builton top of ECL (embedded common lisp). This "new Python library", which isn't so new, since I started it in 2004, is now nearly a million lines of code. [1] https://github.com/sagemath/sage/tree/master/src/sage https://github.com/sagemath/sage/tree/master/src/sage