On Friday, April 15, 2016 at 1:34:57 PM UTC+1, Erik Bray wrote: > > On Thu, Apr 14, 2016 at 5:46 PM, Jeroen Demeyer <[email protected] > <javascript:>> wrote: > > On 2016-04-14 17:38, Erik Bray wrote: > >> > >> Sage already has the problem of large > >> chunks of code that are effectively unmaintained and create a > >> maintenance burden on anyone serious about maintaining sage. Their > >> interfaces whither, and become inconsistent with the rest of the > >> package. It's dead weight. > > > > I disagree with the above. It's not necessarily a problem to have > > unmaintained-but-still-working code. > > It is a problem to have unmaintained and maybe working but poorly > tested and poorly integrated code that nobody knows how to maintain > anymore and that doesn't meet the coding and interface standards of > the rest of the package. >
sagenb is a good example here. A lot of it is a very old javascript code, mixed up with twisted and its callbacks, and other partly outdated web design things, that perhaps noone actively involved in Sage project proper understands now. Attempts to replace it completely with something newer are stalled. It actually appears to be a legacy that has to be maintained for long time, as there textbooks and courses developed and relying on it... There were attempts to improve it, which also failed, not the least by existence of better alternatives (SMC and Jupyter nb). > My greatest joy as a software engineer is almost always deleting code > not adding it. > > I think part of the larger problem of this discussion about > modularization is that nobody has made any concrete proposals yet. > You and others state that there are parts of Sage that are too > difficult to separate out because they're too deeply intertwined. But > nobody is necessarily proposing making cuts in those places. In some > cases maybe the extent of their circular dependency should be taken as > evidence of a need for refactoring. But I also believe you that there > are large parts where this is not the case. Those parts I believe > mostly make up the core package and shouldn't be broken up. > the core problem is that the core package is actually very big. It is probably 80% of Sage library. And it has circular dependencies simply due to the fact that they follow circular mathematical dependencies of various mathematical concepts (e.g. posets depend on graphs, graphs depend on posets, matroids depend on graphs and posets, yet graphs and posets also depend on matroids; all the three depend on a lot of algebra, llinear and not, and again the other way around, etc etc) There a clear outliers, like finances, sagenb, graphics, and duplicates (functionality-wise), such as two different interefaces to GAP (pexpect and libGAP), to Maxima (pexpect vs library), Cutting these out would already be a huge improvement... (but e.g. completely replacing GAP with libGAP is quite a job...) > > Perhaps some of us who support "modularization" as a general principle > should work together to discuss a specific proposal as to where to > make cuts and how to maintain this. Then it would be easier to > discuss the merits and problems with *specific* modifications, rather > than circular discussions about hypotheticals that may or may not be > relevant. > > I'd certainly be interested in having that discussion with anyone else > interested. I don't know most of the Sage package well enough though > to know where to begin. > > Thanks, > Erik > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
