On Tue, Nov 3, 2009 at 1:02 AM, Florent Hivert <florent.hiv...@univ-rouen.fr> wrote: > > Hi > >> > IMHO, Sage should be aiming to be more like the professional maths >> > package, not >> > itunes or Firefox. >> >> What are they like? My main experience with deprecation in the Ma's >> is with Maple and Magma. >> >> - Maple -- has an idiotic, confusing and contradictory mix of upper >> and lowercase linear algebra functionality, because they are too >> scared to remove deprecated code. Yet still, they definitely do break >> old code with new Maple versions sometimes. > > My experience with Maple is pretty old since I decided to leave maple for > MuPAD in 2001, but this was one of the main reason why we (the team in > Marne-la-Vallée) left them. We started from Maple version 2. And each release > until Maple version 7 has been a very large pain for us. At this time the > package ACE was already of a large size (approx 500 functions). Here are some > example of incompatibilities: > - change of the semantic of operation + and * for lists; > - change of the structure of a package; > - change of the indexation of the lists. > ... > For us those were very fundamental change and our code needed to be completely > rewritten. I never launched a maple session since 2003, so that I don't know > if it's better now, but I don't think they had any care for backward > compatibilities at this time. > > Note that my argument is twofold since they actually pushed me away... > > > > By the way, though some part of sage are already very polished, I personally > think sage has being still in a beta stage. Lots of things are far from being > stable and moreover, it is very incoherent in its design from one part to the > other. Furthermore, the quality of the doc is very variable. I don't intend > any offense but I think this as a fact. We all do that on our spare time and > we all are inclined to do what we like. > > As a consequence, pretending to be stable to early is very dangerous. I think > its a very good way to scare newcomers away. So I think we should keep our > extremely good work and not spend too much time pretending it is better than > it really is. I hope I'm won't offend anyone; I also hope that I'm not > starting a flamewar...
On the contrary, I wish you would go into detail about the parts that are good and polished in sage and that parts that aren't. It would be a great spur to development to have a systematic accounting of such things. Moreover, it makes great fodder to include in grant proposals (it's harder to get money to improve Sage if Sage is *not* "beta quality"). * "Lots of things are far from being stable": Which things? Let's make concrete lists so we know where to focus effort. * "Sage is very incoherent in its design from one part to the other." Which parts? From my perspective, Sage is very *coherent* because essentially all of the things I use a lot I designed! But the perspective is completely different to somebody else who uses a totally different 5% of Sage. It would be useful to hear details about lack of coherency in the design. * "Furthermore, the quality of the doc is very variable." Which parts are lesser? Again, having a concrete survey that lists parts of the documentation that are seriously lacking by some metric would be very useful, not only to spur further work, but for grant proposals. William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
