On Tue, Apr 12, 2016 at 7:11 AM, kcrisman <kcris...@gmail.com> wrote: > This has been an interesting thread. In the end, I think that some (or a > lot) of Sage's attractiveness to end users goes away if it becomes a bunch > of possibly-updated packages that might or might not work with a current > version of Sage. I always found the "with(plots)" syntax (or whatever it > was) in Maple very frustrating, and that is presumably a 'core' package; > having random stuff suddenly not work (let me be clear, because it was left > behind by Sage core) would be even more so - as has been pointed out several > times here.
I am a little annoyed, since this completely misunderstands my proposal. 1. My proposal was to make it easier for people to develop new code independently of the core sage library. This in itself has nothing to do with taking away from the existing library or in fact changing it in any way (at least initially). 2. Moreover, to directly address your concern, if 3d plotting (say) were split off as a separate Python package/library, that does *not* imply that when you download and install Sage, or start it, that you can even tell the difference. It doesn't mean that the normal visible public API of Sage changes at all. Why do you think otherwise? We would just include that Python library as a standard package, just like the hundred other standard packages. Volker has mentioned several times how Python enables doing this sort of thing pretty easily already. > Sage users (and potential ones) I speak with want more than just the "basic" > functionality, because they want something they can use throughout the > curriculum and in their own research. There are other (good) tools for > those who truly won't be doing anything beyond calculus. > > Now it's true that some material in Sage probably could have been in > separate packages, as it's quite specialized - likely a lot of the > sage-combinat stuff, the designs stuff, modular forms stuff (elliptic curves > are actually more popular, I think). But then there's the opposite problem > of finding out how to enforce that a package must compile with the most > recent Sage. This is R's model, but R tends to have a very different type > of package, one that implements something relatively narrow. Also, we don't > have the auto-testing resources of R. 1. There can and should exist packages that depend on the core Sage library and have a relatively narrow focus. Why not? 2. Maybe we don't have the same auto-testing resources as R does today. Who is to say we won't in a year or two? I'm planning for a future where the Sage project *does* have resources, and where it is possible to hire 2+ people fulltime to maintain Sage, like what ODK is doing *right now*. That's what we should be aiming for. We have it right now (due to ODK) with Erik and Jereon, at least, and if SageMath Inc succeeds, then it will be possible to continue and grow this. > > The problems that Luca and Simon are (rightly) pointing out, in my view, are > not solved by more modularity - if anything, the problems were because they > were not part of 'standard' Sage, though I of course am not suggesting they > should have been part of it. Their problems were partly caused by us not supporting and encouraging the creation of code outside of standard Sage. We should be doing that 1000x what we are doing now. Right now, we as a community (not me, but certainly many others) are shockingly discouraging and negative toward any code that isn't officially in the core sage library. I think this situation is really baffling to see for a lot of outsiders. > As an example of what happens with the package system, consider several > Maxima packages (which shall remain unnamed) which don't work well with > other Maxima commands/flags/packages (no doubt rjf would say we are using > them improperly, which may be true). Well, they're separate packages, with > their own maintainers, and I don't know that anyone beyond them takes > responsibility, and fixing lots and lots of hard-to-track-down bugs once > you've put in the initial effort is very daunting and time-consuming. So > they kind of languish, I think - not that some Sage bugs don't too, but > there is less likelihood that someone else will take the time to work on > them if it's "just a package", perhaps with its own separate web > affiliation. Just because some people have zero funding and are bad at packaging doesn't mean that the mainstream standard mature approach to open source software development, as exemplified in many ecosystems now (R, Pypi, npm, Debian, etc.) is broken. > (I'm sure the same thing applies to many user-contributed Mma and Maple > packages, but I don't listen in on their ecosystems - I mean upgrades > breaking them, that is. They are fairly monolithic, though?) > > To be clear, I'm only talking about the core Sage library; if people can > find a way to make the other stuff more like sage-on-Gentoo without making > it really, really hard to use on any setup other than the most popular > distros/most bleeding-edge Mac OS, that is great. > > I also don't have a problem with things like psage or any other such > packages (as I think William is proposing in this thread for much of the > functionality), but the experience thus far has been that the successful > such things are eventually merged in Sage proper, rather than being > contingent. Extreme selection bias. Our community strongly forces things to fail if they aren't "merged in Sage proper". You then look at that and conclude things that succeed do so because they are merged in Sage proper. > Think of how much time has been spent on managing the > sage-combinat queue or branch or whatever to make sure it always works ... > *Given our constraints on testing*, building the car was the right idea > then, and it's still the right idea now. Cars are built out of parts. > And I would rather have the car that can drive everywhere - for me, for my > students, for my colleagues - against the car that needs fancy upgrades that > are often not available on my model. Volker's original comment still holds: > "As long as the goal of "import sage" is to give you something like the > feature set of Sage right now we don't benefit from modularization. That is > just a tautology, the goal is just not a modular one. We'd just shoot > ourselves in the foot if we split things into multiple interdependent > packages that then must be upgraded in lockstep." Modularization -- one of the most basic and important ideas in software engineering -- is not shooting ourselves in the foot. -- William > > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
