Only trying to foster a (constructive) discussion, by suggesting a way to talk about the development...
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/...). 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). 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.
