On Tue, Apr 12, 2016 at 7:33 PM, William Stein <wst...@gmail.com> wrote: > 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.
Okay, and this is what I get for not reading further downthread before replying--I see we're in agreement here. Erik >> 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. -- 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.
