On Fri, Nov 23, 2012 at 8:02 AM, Paul-Olivier Dehaye <paul-olivier.deh...@math.uzh.ch> wrote: > Only trying to foster a (constructive) discussion, by suggesting a way to > talk about the development...
Thank you. > I think issues in our development model could be resolved if we adhered > strictly to principles of aspect oriented software development. > http://en.wikipedia.org/wiki/Aspect-oriented_software_development > Our "business" is to "serve the best mathematical information for our users" > (what best means depends on the user and his/her goal at that instant: > teach/learn/research/...). I have to admit, even after reading the article, it's still really vague to me what AOSD is. Could you sum it up in a paragraph (especially as it applies to Sage). > Here is a list I have been compiling in the past > few days of different issues that pop up regularly on math-devel and might > be useful to consider as "cross-cutting concerns" in the sense of that > wikipedia link: > > - mathematical abstraction (parts of the categories framework will help > structure all this abstraction in the long run, but we have actually spread > our collective mathematical knowledge all over the place) > - logging > - documentation > - testing > - persistence (pickling, cached_function, cached_method, databases, etc. > For info: > ~> grep -R "loads(dumps" * | wc -l > 1368 > ) > - exactness/correctness (for instance the issue Nathann is raising in this > thread) > - speed > - coercions/types > - inputs of the sage system (notebook, preparser, command line interface, > ...) > - outputs of the sage system (notebook, latex, other CAS) > - deprecation > - cross-compatibility (for instance with Solaris) > - parallelism > - precision issues > - tutorials > - conventions (French or English notation for tableaux, arithmetic or > analytic normalization for L-function, D4 or D8?) > - actually organizing and performing computations > - explaining how results were obtained (whether or not to send warnings for > instance, is it conjectural) > - street credit for algorithm discovery, implementation, data, ... > - version control (at the moment we do this with outside tools) > - patch submission ((at the moment we do this with outside tools) > - bug report > - development model (version control, patch submission, bug reports are > parts of this, also interferes with the testing aspect) > - use case (building a great system in the long run, doing research right > now, teaching) > - ... > > The last point is meant to highlight that we write code not only for many > different people but also that each person might have more than one goal in > mind. > > I think organizing our code into aspects would help fix bugs (localizing > changes into less files) and move faster. It would also help welcome new > people to sage (minimizing investment needed). It would clarify things too > (for instance, the categories framework, as it currently exists, is an > aggregation of several of the aspects listed above: strong flavor of > mathematical abstraction, Parent/Element, and like everywhere else, some > testing and documenting). Could you give some concrete examples of how one could better organize one of the "aspects" above. For example, in coercion, there is "scatter" in the implementation of the various coercions, but I think this is better than having a single location in the code that knows about every parent. (There is a central framework mostly in sage/structure/{element,parent,coerce}.pyx, are you suggesting that be arranged better?) Likewise documentation, testing (doctests), and persistence (pickling at least) are widely "scattered," but this is to preserve locality with the functionality (e.g. it would seem bad practice to have a single module that knows how to pickle everything). Or how would one localize the issues of speed? Perhaps I'm just not following the suggestion. I think there are conventions for much of this (e.g. the global proof object, and proof flags in methods, for separating conjectural vs. known results), but a lot could be better documented (though at some point it's easy to drown a new user/developer in documentation). cached_function and cached_method as decorators already seem to embody AOSD, right? > The development gets tricky whenever code is written and people read it with > a different set of concerns in mind. They are forced to: we have no > mechanism to define most of these concerns, and thus no way of making code > dependent on the state of any of those concerns. > > We should be able to identify atomic aspects by simple discussion, on this > list for instance. > > This email is simply meant as a suggestion on how to frame the discussion. > Please do not shut down this avenue of thinking purely on the grounds that > - "It would be nice, but it is a dream": I have made no attempt to explain > how one might concretely implement this (we are of course already > separating some of the concerns above). You might think it's a dream, but > please consider that at least one person is thinking about how to do it. > - "What's the point": Sorry you missed it, re-read the email. > - "This will slow down the one class I am using a lot": Not if it's done > right. > > Paul > > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > 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. > Visit this group at http://groups.google.com/group/sage-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
